Azure에 대한 서비스 주체 액세스 권한 부여

6분

서비스 주체 자체는 Azure 환경에서 아무 것도 수행할 수 없습니다. 이는 사용자가 사용 권한이 부여되지 않는 한 Azure 리소스로 작업할 수 없는 것과 같습니다. 이 단원에서는 불필요한 사용 권한을 부여하지 않고 서비스 주체에게 Azure 리소스를 배포하고 구성하도록 권한을 부여하는 방법을 알아봅니다.

참고

이 단원의 명령은 개념을 설명하기 위해 표시된 것입니다. 명령을 아직 실행하지 마세요. 여기에서 학습하는 내용을 곧 연습할 예정입니다.

서비스 주체 권한 부여

지금까지 서비스 주체란 무엇인지, 이를 사용하여 Microsoft Entra ID에 대한 파이프라인 ID를 어떻게 증명하는지에 집중했습니다. 이는 모두 인증에 관한 것입니다.

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

참고

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

파이프라인에 적합한 역할 할당 선택

역할 할당에는 역할이 할당된 사람(담당자),수행할 수 있는 작업(역할), 역할 할당이 적용되는 리소스(범위)의 세 가지 핵심 부분이 있습니다.

담당자

서비스 주체를 사용하여 작업할 때 해당 서비스 주체에 대한 역할을 할당합니다. 서비스 주체의 애플리케이션 ID를 사용하여 해당 담당자에 대한 올바른 서비스 주체를 식별합니다.

역할

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

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

주의

서비스 주체에게 해당 작업을 수행하는 데 필요한 최소 사용 권한만 부여해야 합니다. 대부분의 경우 소유자 역할은 배포 파이프라인에 대해 너무 관대합니다.

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

참고 항목

사용자 지정 역할 정의는 Azure 리소스에 대한 사용 권한을 부여하는 강력한 방법이 될 수 있지만 작업하기가 어려울 수 있습니다. 사용자 지정 역할 정의에 추가해야 하는 사용 권한을 정확하게 확인하는 것이 항상 쉬운 것은 아니며, 실수로 역할 정의를 너무 제한적이거나 너무 허용적으로 만들 수 있습니다. 수행할 작업이 무엇인지 잘 모르겠는 경우 기본 제공 역할 정의 중 하나를 대신 사용하는 것이 가장 좋습니다. 사용자 지정 역할 정의는 이 모듈에서 다루지 않습니다.

범위

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

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

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

올바른 역할 할당 선택

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

가능한 한 최소한의 권한을 부여하는 역할을 사용합니다. 파이프라인이 기본 Bicep 템플릿만 배포하고 역할 할당을 관리하지 않는 경우 소유자 역할을 사용하지 마세요.
가능한 한 가장 좁은 범위를 사용합니다. 대부분의 파이프라인은 리소스 그룹에 리소스를 배포하기만 하면 되므로 구독 범위 역할 할당이 제공되지 않아야 합니다.
많은 파이프라인의 경우 역할 할당에 대한 좋은 기본 옵션은 리소스 그룹 범위의 참가자 역할입니다.
파이프라인이 수행하는 모든 것과 나중에 수행할 수 있는 모든 작업을 고려합니다. 예를 들어 웹 사이트의 배포 파이프라인에 대한 사용자 지정 역할 정의를 만들고 App Service 및 Application Insights에 대한 사용 권한만 부여하는 것이 좋습니다. 다음 달에 Bicep 파일에 Azure Cosmos DB 계정을 추가해야 할 수도 있지만 사용자 지정 역할은 Azure Cosmos DB 리소스 생성을 차단합니다. 대신, 기본 제공 역할 또는 기본 제공 역할의 조합을 사용하여 역할 정의를 반복적으로 변경할 필요가 없도록 하는 것이 좋습니다. Azure Policy를 사용하여 허용된 서비스, SKU 및 위치에 대한 거버넌스 요구 사항을 적용하는 것이 좋습니다.
파이프라인을 테스트하여 역할 할당이 작동하는지 확인합니다.

역할 할당 혼합 및 일치

여러 범위에서 서로 다른 사용 권한을 제공하는 여러 역할 할당을 만들 수 있습니다. 예를 들어 서비스 주체에게 전체 구독 범위의 읽기 프로그램 역할을 할당한 다음, 동일한 서비스 주체에게 특정 리소스 그룹에 대한 참가자 역할을 별도로 할당할 수 있습니다. 서비스 주체가 리소스 그룹을 사용하여 작업하려고 하는 경우 더욱 허용되는 할당이 적용됩니다.

여러 환경 사용

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

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

클러스터 서비스 주체에 대한 역할 할당 만들기

서비스 주체에 대한 역할 할당을 만들려면 az role assignment create 명령을 사용합니다. 담당자, 역할 및 범위를 지정해야 합니다.

az role assignment create \
  --assignee b585b740-942d-44e9-9126-f1181c95d497 \
  --role Contributor \
  --scope "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

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

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

서비스 주체에 대한 역할 할당을 만들려면 New-AzRoleAssignment cmdlet을 사용합니다. 담당자, 역할 및 범위를 지정해야 합니다.

New-AzRoleAssignment `
  -ApplicationId b585b740-942d-44e9-9126-f1181c95d497 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

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

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

팁

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

참고

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

하나의 작업에서 서비스 주체 및 역할 할당 만들기

서비스 주체를 만드는 동시에 역할 할당을 만들 수도 있습니다. 코드는 이전 단위에서 서비스 주체를 만드는 데 사용한 명령과 유사하지만 몇 가지 추가 인수가 있습니다.

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

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

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

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c과(와) 같은 정규화된 리소스 ID를 사용하여 이를 표현합니다.
principalId은(는) 서비스 주체의 개체 ID입니다. 애플리케이션 ID 또는 애플리케이션 등록의 개체 ID를 사용하지 않도록 유의합니다.
description은(는) 역할 할당에 대한 사람이 읽을 수 있는 설명입니다.

계속

서비스 주체 권한 부여

파이프라인에 적합한 역할 할당 선택

담당자

역할

범위

올바른 역할 할당 선택

역할 할당 혼합 및 일치

여러 환경 사용

클러스터 서비스 주체에 대한 역할 할당 만들기

하나의 작업에서 서비스 주체 및 역할 할당 만들기

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

피드백