GitHub Actions 워크플로에 대한 워크플로 ID 만들기
워크로드 ID의 개념을 이해했으므로 워크로드 ID를 만들고 GitHub Actions 배포 워크플로에 연결하는 방법이 궁금할 수 있습니다. 이 단원에서는 이를 수행하는 단계를 보여줍니다.
Microsoft Entra 애플리케이션 만들기
이전 단원에서는 워크로드 ID가 Microsoft Entra ID에서 애플리케이션 등록을 만들어야 한다는 것을 배웠습니다.
참고 항목
애플리케이션 등록을 만들고 수정하려면 Microsoft Entra ID 권한이 있어야 합니다. 일부 조직에서는 관리자가 이러한 단계를 수행해야 할 수 있습니다.
애플리케이션 등록을 만들 때 표시 이름을 지정해야 합니다. 표시 이름은 애플리케이션 등록을 설명하는 사람이 읽을 수 있는 이름입니다.
팁
애플리케이션 등록에 대해 명확하고 설명이 포함된 표시 이름을 사용합니다. 사용자가 실수로 삭제하거나 사용 권한을 변경하지 않도록 팀이 애플리케이션 등록의 역할을 이해하도록 돕는 것이 중요합니다.
다음은 새 Microsoft Entra 애플리케이션을 만드는 Azure CLI 명령의 예입니다.
az ad app create --display-name $applicationRegistrationName
다음은 새 Microsoft Entra 애플리케이션을 만드는 Azure PowerShell 명령의 예입니다.
New-AzADApplication -DisplayName $applicationRegistrationName
이전 명령의 출력에는 다음을 비롯한 중요한 정보가 포함됩니다.
- 애플리케이션 ID: 애플리케이션 등록에는 종종 애플리케이션 ID 또는 클라이언트 ID라고도 하는 고유 식별자가 있습니다. 워크플로에서 Azure에 로그인해야 하는 경우 이 식별자를 사용합니다.
- 개체 ID: 애플리케이션 등록에는 Microsoft Entra ID에서 할당하는 고유 식별자인 개체 ID가 있습니다. 이 모듈의 뒷부분에서 개체 ID를 사용하는 방법에 대한 예제가 표시됩니다.
애플리케이션 등록을 만들 때 일반적으로 표시 이름만 설정합니다. Azure는 다른 이름과 식별자를 자동으로 할당합니다.
주의
표시 이름은 고유하지 않습니다. 여러 응용 프로그램 등록은 동일한 표시 이름을 공유할 수 있습니다. 애플리케이션 등록을 식별하기 위해 표시 이름을 사용하여 사용 권한을 부여하는 경우 주의해야 합니다. 실수로 잘못된 애플리케이션 등록에 사용 권한을 부여할 수 있습니다. 대신 고유 식별자 중 하나를 사용하는 것이 좋습니다.
페더레이션 자격 증명
ID가 Azure와 통신해야 하는 경우 Microsoft Entra ID에 로그인합니다. 애플리케이션 등록 자체만으로는 워크플로 또는 애플리케이션이 Azure에 로그인할 수 없습니다. 먼저 일부 자격 증명을 할당해야 합니다. 페더레이션 자격 증명은 애플리케이션 자격 증명의 한 가지 유형입니다. 대부분의 자격 증명과 달리 페더레이션 자격 증명은 암호 또는 키와 같은 비밀을 관리할 필요가 없습니다.
배포 워크플로에 대한 페더레이션 자격 증명을 만들 때 Microsoft Entra ID 및 GitHub가 서로 신뢰하도록 효과적으로 지시합니다. 이러한 신뢰를 페더레이션이라고 합니다.
그런 다음 워크플로에서 로그인을 시도할 때 GitHub는 워크플로 실행에 대한 정보를 제공하므로 Microsoft Entra ID 로그인 시도를 허용할지 여부를 결정할 수 있습니다. GitHub가 각 로그인 시도 중에 Microsoft Entra ID에 제공하는 정보에는 다음 필드가 포함될 수 있습니다.
- GitHub 사용자 또는 조직 이름.
- GitHub 저장소 이름.
- 워크플로가 현재 실행 중인 리포지토리의 분기.
- 워크플로 작업이 대상으로 하는 환경. 환경은 뒤에 나오는 모듈에서 알아보겠습니다.
- 끌어오기 요청 만들기가 워크플로를 트리거했는지 여부.
앞서 나열된 속성의 값에 따라 GitHub에서 로그인 시도를 허용하거나 거부하도록 Microsoft Entra ID를 구성할 수 있습니다. 예를 들어 다음 정책을 적용할 수 있습니다.
- 조직 내의 특정 GitHub 리포지토리에서 워크플로가 실행되는 경우에만 로그인 시도를 허용합니다.
- 조직 내의 특정 GitHub 리포지토리에서 워크플로가 실행되고 분기 이름이 기본인 경우에만 로그인 시도를 허용합니다.
다음은 워크로드 ID 및 페더레이션 자격 증명을 사용하여 배포 워크플로가 로그인하는 방법을 보여주는 그림입니다.
로그인 프로세스와 관련된 단계는 다음과 같습니다.
워크플로가 Azure와 통신해야 하는 경우 GitHub는 Microsoft Entra ID를 안전하게 연결하여 액세스 토큰을 요청합니다. GitHub는 GitHub 조직(
my-github-user), 리포지토리(my-repo) 및 워크플로가 실행 중인 분기(main)에 대한 정보를 제공합니다. 또한 Microsoft Entra ID 내의 테넌트 ID, 워크플로 ID 애플리케이션 등록의 애플리케이션 ID 및 워크플로가 배포하려는 Azure 구독 ID도 포함합니다.Microsoft Entra ID는 애플리케이션 ID의 유효성을 검사하고, GitHub 조직, 리포지토리 및 분기에 대해 애플리케이션 내에 페더레이션 자격 증명이 있는지 확인합니다.
Microsoft Entra ID는 요청이 유효한지 확인한 후 액세스 토큰을 발급합니다. 워크플로는 Azure Resource Manager와 통신할 때 액세스 토큰을 사용합니다.
페더레이션 자격 증명 만들기
Azure CLI를 사용하는 경우 JSON 파일 또는 변수를 만들어 페더레이션 자격 증명을 정의합니다. 예를 들어 다음 JSON 파일을 살펴보세요.
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
해당 파일에서 subject 속성은 다음과 같은 상황에서 워크플로가 실행되는 경우에만 페더레이션 자격 증명이 유효해야 한다고 지정합니다.
| 필드 | 값 |
|---|---|
| GitHub 조직 이름 | my-github-user |
| GitHub 리포지토리 이름 | my-repo |
| 분기 이름 | main |
다음과 같이 JSON에서 정책을 만들고 policy.json이라는 파일에 저장한 후 Azure CLI를 사용하여 페더레이션 자격 증명을 만들 수 있습니다.
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Azure PowerShell을 사용하는 경우 다음과 유사한 문자열을 만들어 페더레이션 자격 증명을 정의합니다.
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
위의 문자열은 다음과 같은 상황에서 워크플로가 실행될 때만 페더레이션 자격 증명이 유효해야 한다고 지정합니다.
| 필드 | 값 |
|---|---|
| GitHub 조직 이름 | my-github-user |
| GitHub 리포지토리 이름 | my-repo |
| 분기 이름 | main |
다음과 같이 정책 문자열을 만든 후 Azure PowerShell을 사용하여 페더레이션 자격 증명을 만들 수 있습니다.
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
작업 ID의 수명 주기 관리
만드는 각 워크로드 ID의 전체 수명 주기를 고려하는 것이 중요합니다. 배포 워크플로에 대한 워크로드 ID를 빌드할 때 워크플로를 실수로 삭제하거나 더 이상 사용하지 않을 경우 어떻게 되나요?
워크로드 ID 및 페더레이션된 자격 증명은 자동으로 제거되지 않으므로 이전 것들을 감사하여 제거해야 합니다. 배포 워크플로의 워크로드 ID에 다시 사용할 수 있는 비밀 자격 증명이 없더라도 더 이상 필요하지 않은 경우 제거하는 것이 가장 좋습니다. 이를 통해 누군가가 동일한 이름으로 다른 GitHub 리포지토리를 만들고 예기치 않게 Azure 환경에 액세스할 수 있습니다.
사용자와 팀이 쉽게 액세스할 수 있는 장소에서 워크로드 ID를 문서화하는 것이 좋습니다. 각 워크로드 ID에 대해 다음의 정보를 포함합니다.
- 이름 및 애플리케이션 ID와 같은 키를 식별하는 정보
- 용도
- 만들고, 관리하고, 문제가 있는 경우 이를 해결할 수 있는 사람
- 필요한 사용 권한 및 필요한 이유에 대한 명확한 근거
- 예상 수명
워크로드 ID를 정기적으로 감사하여 계속 사용 중이고 할당된 사용 권한이 여전히 올바른지 확인해야 합니다.