워크로드 ID에 Azure에 대한 액세스 권한 부여

6분

워크로드 ID 자체로는 권한이 부여되지 않은 사용자가 Azure 리소스를 사용할 수 없는 것과 마찬가지로 Azure 환경에서 어떤 작업도 수행할 수 없습니다. 이 단원에서는 불필요한 사용 권한을 부여하지 않고 워크로드 ID에 Azure 리소스를 배포하고 구성하도록 권한을 부여하는 방법을 알아봅니다.

워크로드 ID 권한 부여

지금까지는 워크로드 ID가 무엇이고 이를 사용하여 Microsoft Entra ID에 대한 배포 워크플로의 ID를 증명하는 방법에 중점을 두었습니다. 이는 모두 인증에 관한 것입니다.

Microsoft Entra ID가 워크로드 ID를 인증한 후 다음 질문은 이 워크로드 ID가 무엇을 할 수 있는가 하는 것입니다. 이는 권한 부여의 개념입니다. IAM(ID 및 액세스 관리)이라고도 하는 Azure RBAC(역할 기반 액세스 제어) 시스템의 책임입니다. Azure RBAC를 사용하여 워크로드 ID에 특정 리소스 그룹, 구독 또는 관리 그룹에 대한 액세스 권한을 부여할 수 있습니다.

참고 항목

여기서 수행하는 것은 Azure RBAC 시스템을 사용하여 스토리지 계정, Azure App Service 계획 및 가상 네트워크와 같은 Azure 리소스를 만들고 관리할 수 있는 액세스를 허용하는 것입니다. Microsoft Entra ID에는 디렉터리 역할이라고도 하는 자체 역할 시스템도 있습니다. 이러한 역할을 사용하여 워크로드 ID에 Microsoft Entra ID를 관리할 수 있는 권한을 부여합니다. 이 모듈에서는 이 주제에 대해 심층적으로 논의하지 않지만 일부 설명서의 두 상황 모두에 역할이라는 용어를 사용합니다.

워크플로에 적합한 역할 할당 선택

역할 할당에는 역할이 할당된 대상(담당자), 수행할 수 있는 작업(역할), 역할 할당이 적용되는 리소스(범위)라는 세 가지 주요 부분이 있습니다.

담당자

워크로드 ID를 사용하는 경우 그에 대한 역할을 할당합니다. 역할을 할당하려면 먼저 Azure에서 애플리케이션 역할을 부여할 수 있는 서비스 주체를 만들어야 합니다. 서비스 주체를 만들면 애플리케이션 등록의 애플리케이션 ID로 계속 작업할 수 있습니다.

서비스 주체를 만들려면 az ad sp create 명령을 사용하고 애플리케이션 등록의 앱 ID를 지정합니다.

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

서비스 주체를 만들려면 New-AzADServicePrincipal cmdlet을 사용하고 애플리케이션 등록의 앱 ID를 지정합니다.

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

역할

어떤 역할을 할당할 것인지 파악하기 위해 좀 더 많은 작업이 있을 수 있습니다. Azure에는 몇 가지 일반적인 역할이 있습니다.

읽기 권한자: 담당자가 리소스에 대한 정보를 읽을 수 있지만 수정하거나 삭제할 수는 없습니다.
기여자: 담당자가 리소스를 만들고 기존 리소스를 읽고 수정할 수 있도록 허용합니다. 그러나 참가자는 다른 보안 주체에게 리소스에 대한 액세스 권한을 부여할 수 없습니다.
소유자: 다른 보안 주체 액세스 권한 부여를 포함하여 리소스에 대한 모든 컨트롤을 가집니다.

주의

워크로드 ID에 해당 작업을 수행하는 데 필요한 최소 사용 권한만 부여해야 합니다. 대부분의 경우 소유자 역할은 배포 워크플로에 대해 너무 관대합니다.

기능의 하위 집합에 대한 액세스만 제공하는 특정 역할도 많습니다. 사용자 고유의 사용자 지정 역할 정의를 만들어 할당하려는 사용 권한의 정확한 목록을 지정할 수도 있습니다.

참고

사용자 지정 역할 정의는 Azure 리소스에 대한 사용 권한을 부여하는 강력한 방법이 될 수 있지만 작업하기가 어려울 수 있습니다. 사용자 지정 역할 정의에 추가해야 하는 권한을 정확하게 확인하는 것이 항상 쉬운 것은 아닙니다. 실수로 역할 정의를 너무 제한적이거나 너무 허용적으로 만들 수 있습니다.

수행할 작업이 무엇인지 잘 모르겠는 경우 기본 제공 역할 정의 중 하나를 사용하는 것이 가장 좋습니다. 사용자 지정 역할 정의는 이 모듈에서 다루지 않습니다.

범위

역할을 얼마나 광범위하게 할당할지 판단해야 합니다. 이 판단은 워크로드 ID가 수정할 수 있는 리소스 수에 영향을 미칩니다. 일반적인 범위는 다음과 같습니다.

단일 리소스: 특정 리소스에 대한 액세스 권한만 부여할 수 있습니다. 이 범위는 아직 존재하지 않는 리소스를 만들거나 여러 리소스를 다시 구성하기 때문에 배포 워크플로은 일반적으로 이 범위를 사용하지 않습니다.
리소스 그룹: 리소스 그룹 내의 모든 리소스에 대한 액세스를 허용할 수 있습니다. 참가자 및 소유자는 그룹 내에서 리소스를 만들 수도 있습니다. 이는 배포 워크플로가 많은 경우 적합한 옵션입니다.
구독: 구독 내의 모든 리소스에 대한 액세스를 허용할 수 있습니다. 단일 구독에 여러 애플리케이션, 워크로드 또는 환경이 있는 경우 구독 범위에 사용 권한을 부여할 수 있습니다. 그러나 이는 배포 워크플로에 너무 허용적인 경우가 일반적입니다. 대신 배포 워크플로에서 리소스 그룹을 만들어야 하는 경우가 아니면 역할 할당 범위를 리소스 그룹에 지정하는 것이 좋습니다.

역할 할당은 상속된다는 점을 명심하세요. 구독에서 역할을 할당하면 담당자는 해당 구독 내의 모든 리소스 그룹 및 리소스에 액세스할 수 있습니다.

올바른 역할 할당 선택

이제 역할 할당의 구성 요소를 이해하게 됐으므로 시나리오에 적합한 값을 결정할 수 있습니다. 고려해야 할 일반적인 지침은 다음과 같습니다.

가능한 한 최소한의 권한을 부여하는 역할을 사용합니다. 워크플로가 기본 Bicep 파일만 배포하고 역할 할당을 관리하지 않는 경우 소유자 역할을 사용하지 마세요.
가능한 한 가장 좁은 범위를 사용합니다. 대부분의 워크플로는 리소스 그룹에 리소스를 배포하기만 하면 되므로 구독 범위 역할 할당이 제공되지 않아야 합니다.
많은 워크플로의 경우 역할 할당에 대한 좋은 기본 옵션은 리소스 그룹 범위의 참가자 역할입니다.
워크플로가 수행하는 모든 작업과 나중에 수행할 수 있는 모든 작업을 고려합니다. 예를 들어 웹 사이트의 배포 워크플로에 대한 사용자 지정 역할 정의를 만들고 App Service 및 Application Insights에 대한 사용 권한만 부여하는 것이 좋습니다. 다음 달에 Bicep 파일에 Azure Cosmos DB 계정을 추가해야 할 수도 있지만 사용자 지정 역할은 Azure Cosmos DB 리소스 생성을 차단합니다.

대신, 기본 제공 역할 또는 기본 제공 역할의 조합을 사용하여 역할 정의를 반복적으로 변경할 필요가 없도록 하는 것이 좋습니다. Azure Policy를 사용하여 허용된 서비스, SKU 및 위치에 대한 거버넌스 요구 사항을 적용하는 것이 좋습니다.
워크플로를 테스트하여 역할 할당이 작동하는지 확인합니다.

역할 할당 혼합 및 일치

여러 범위에서 서로 다른 사용 권한을 제공하는 여러 역할 할당을 만들 수 있습니다. 예를 들어 워크로드 ID에 전체 구독의 범위를 포함한 읽기 권한자의 역할을 할당할 수 있습니다. 동일한 워크로드 ID에 특정 리소스 그룹에 대한 기여자의 역할을 개별적으로 할당할 수 있습니다. 워크로드 ID가 리소스 그룹을 사용하여 작업하려고 하는 경우 더욱 허용되는 할당이 적용됩니다.

여러 환경 사용

애플리케이션의 개발, 테스트 및 프로덕션 환경과 같은 여러 환경에서 작업할 수 있습니다. 각 환경의 리소스는 서로 다른 리소스 그룹 또는 구독에 배포되어야 합니다.

각 환경에 대해 별도의 워크로드 ID를 만들어야 합니다. 배포에 필요한 최소 사용 권한 집합을 각 워크로드 ID에 부여합니다. 프로덕션 배포에 대한 사용 권한과 비프로덕션 환경에 배포하는 권한이 혼합되지 않도록 특히 주의해야 합니다.

워크로드 ID에 대한 역할 할당 만들기

워크로드 ID에 대한 역할 할당을 만들려면 az role assignment create 명령을 사용합니다. 담당자, 역할 및 범위를 지정해야 합니다.

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

각 인수를 살펴보겠습니다.

--assignee는 워크로드 ID를 지정합니다. 여러 가지 방법으로 지정할 수 있지만 모호성을 방지하려면 애플리케이션 ID를 사용하는 것이 좋습니다.
--role은(는) 역할을 지정합니다. 기본 제공 역할을 사용하는 경우 이름으로 지정할 수 있습니다. 사용자 지정 역할 정의를 사용하는 경우 전체 역할 정의 ID를 지정하세요.
--scope은(는) 범위를 지정합니다. 이는 일반적으로 단일 리소스, 리소스 그룹 또는 구독에 대한 리소스 ID입니다.
--description은(는) 역할 할당에 대한 사람이 읽을 수 있는 설명입니다.

워크로드 ID에 대한 역할 할당을 만들려면 New-AzRoleAssignment cmdlet을 사용합니다. 담당자, 역할 및 범위를 지정합니다.

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

각 인수를 살펴보겠습니다.

-ApplicationId는 워크로드 ID의 애플리케이션 등록 ID를 지정합니다.
-RoleDefinitionName는 기본 제공 역할의 이름을 지정합니다. 사용자 지정 역할 정의를 사용하는 경우 -RoleDefinitionId 인수를 대신 사용하여 전체 역할 정의 ID를 지정합니다.
-Scope은(는) 범위를 지정합니다. 이는 일반적으로 단일 리소스, 리소스 그룹 또는 구독에 대한 리소스 ID입니다.
-Description은(는) 역할 할당에 대한 사람이 읽을 수 있는 설명입니다.

팁

설명을 지정하여 역할 할당에 대한 근거를 제공하는 것이 좋습니다. 설명은 나중에 역할 할당을 검토하는 모든 사용자가 목적을 이해하고 담당자, 역할 및 범위를 결정하는 방법을 이해하는 데 도움이 됩니다.

참고

역할 할당은 활성화되는 데 몇 분 정도 걸릴 수 있습니다.

Bicep을 사용하여 액세스 권한 부여

역할 할당은 Azure 리소스입니다. 이는 Bicep을 사용하여 역할 할당을 만들 수 있다는 것을 의미합니다. Bicep을 사용하여 리소스 그룹을 초기화한 다음, 워크로드 ID를 사용하여 리소스 그룹에 리소스를 배포하는 경우 이 작업을 수행할 수 있습니다. 앞의 역할 할당에 대한 Bicep 정의 예제는 다음과 같습니다.

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

각 인수를 살펴보겠습니다.

name은 역할 할당에 대한 GUID(Globally Unique Identifier)입니다. Bicep에서 guid() 함수를 사용하여 GUID를 만드는 것이 좋습니다. 각 역할 할당에 대해 고유한 이름을 만들려면 주체 ID, 역할 정의 ID 및 범위를 함수의 시드 인수로 사용합니다.
principalType는 ServicePrincipal로 설정되어야 합니다.
roleDefinitionId는 사용자가 할당한 역할 정의에 대해 정규화된 리소스 ID입니다. 대부분의 경우 기본 제공 역할로 작업하므로 Azure 기본 제공 역할 설명서에서 역할 정의 ID를 찾을 수 있습니다.

예를 들어 참가자 역할에는 역할 정의 ID b24988ac-6180-42a0-ab88-20f7382dd24c이(가) 있습니다. Bicep 파일에서 지정하는 경우 /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c와 같은 정규화된 리소스 ID를 사용합니다.
principalId은(는) 서비스 주체의 개체 ID입니다. 애플리케이션 ID 또는 애플리케이션 등록의 개체 ID를 사용하지 않도록 유의합니다.
description은(는) 역할 할당에 대한 사람이 읽을 수 있는 설명입니다.

워크로드 ID에 Azure에 대한 액세스 권한 부여

워크로드 ID 권한 부여

워크플로에 적합한 역할 할당 선택

담당자

역할

범위

올바른 역할 할당 선택

역할 할당 혼합 및 일치

여러 환경 사용

워크로드 ID에 대한 역할 할당 만들기

Bicep을 사용하여 액세스 권한 부여

피드백