ワークロード ID に Azure へのアクセス権を付与する

• 6 分

ワークロード ID は、単独では Azure 環境で何も実行できません。これは、ユーザーが操作する権限を与えられていない限り、Azure リソースを操作できないのと同じです。 このユニットでは、不要なアクセス許可の付与を回避しながら、ワークロード ID による Azure リソースのデプロイおよび構成を承認する方法について学習します。

ワークロード ID の認可

ここまでは、ワークロード ID の概要と、それらを使用して、Microsoft Entra ID に対してデプロイ ワークフローの身元を証明する方法に焦点を当ててきました。 これは、すべて "認証" に関するものです。

Microsoft Entra ID がワークロード ID を認証した後、次の疑問として浮かぶのは、このワークロード ID は何ができるのかということです。 これは "認可" の概念です。 これは、Azure のロールベースのアクセス制御 (RBAC) システム (場合により ID およびアクセス管理 (IAM) とも呼ばれる) の役割です。 Azure RBAC を使用すると、特定のリソース グループ、サブスクリプション、または管理グループへのアクセス権をワークロード ID に付与できます。

ワークフローに適したロールの割り当てを選択する

ロールの割り当てには、ロールを割り当てるユーザー ("担当者")、担当者が実行できる内容 ("ロール")、ロールの割り当てが適用される 1 つまたは複数のリソース ("スコープ") という 3 つの重要な構成要素があります。

担当者

ワークロード ID を使用する場合は、それにロールを割り当てます。 ロールを割り当てるには、まず "サービス プリンシパル"を作成する必要があります。これにより、Azure でアプリケーション ロールを付与できるようになります。 サービス プリンシパルを作成したら、アプリケーション登録のアプリケーション ID を引き続き使用できます。

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

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

Role

割り当てるロールを判断するのに、多少労力が必要になる場合があります。 Azure には、一般的なロールがいくつかあります。

• 閲覧者: 担当者は、リソースに関する情報を読み取ることができますが、それらを変更または削除することはできません。
• 共同作成者:担当者は、リソースの作成、既存のリソースの読み取りと変更を行うことができます。 ただし、共同作成者は、リソースへのアクセス権を他のプリンシパルに付与することはできません。
• 所有者: 他のプリンシパルへのアクセス権の付与など、リソースを完全に制御できます。

また、機能のサブセットへのアクセス権を提供する特定のロールも多数あります。 独自の "カスタム ロールの定義" を作成して、割り当てるアクセス許可の正確な一覧を指定することもできます。

Scope

ロールを割り当てる範囲を決定する必要があります。 この決定は、ワークロード ID によって変更できるリソースの数に影響します。 一般的なスコープは次のとおりです。

• 単一リソース: 特定のリソースへのアクセス権を付与できます。 通常、デプロイ ワークフローでは、このスコープは使用されません。その理由は、ワークフローで、まだ存在しないリソースが作成されたり、複数のリソースが再構成されたりするためです。
• リソース グループ: リソース グループ内のすべてのリソースへのアクセス権を付与できます。 共同作成者と所有者は、グループ内でリソースを作成することもできます。 これは、多くのデプロイ ワークフローに適したオプションです。
• サブスクリプション: サブスクリプション内のすべてのリソースへのアクセス権を付与できます。 1 つのサブスクリプションに複数のアプリケーション、ワークロード、または環境がある場合、サブスクリプションのスコープへのアクセス許可を付与できます。 ただし、これは通常、デプロイ ワークフローに対しては制限が緩すぎます。 代わりに、ロールの割り当てのスコープをリソース グループに設定することを検討する必要があります (デプロイ ワークフローでリソース グループを作成する必要がある場合を除きます)。

ロールの割り当ては継承されることに注意してください。 サブスクリプションでロールを割り当てると、担当者は、そのサブスクリプション内のすべてのリソース グループとリソースにアクセスできます。

適切なロールの割り当ての選択

ロールの割り当ての要素について理解したので、シナリオに適した値を決定できます。 ここでは、考慮する必要がある一般的なガイドラインを示します。

ロールの割り当ての混在と一致

異なるスコープで異なるアクセス許可を提供する複数のロールの割り当てを作成できます。 たとえば、ワークロード ID に、サブスクリプション全体をスコープとする閲覧者のロールを割り当てたとします。 同じワークロード ID に、特定のリソース グループに対する共同作成者のロールを別途割り当てたとします。 ワークロード ID でそのリソース グループを操作しようとしたとき、より制限の緩い割り当てが適用されます。

複数の環境の使用

おそらく、アプリケーションの開発、テスト、運用環境など、複数の環境を使用します。 各環境のリソースは、異なるリソース グループまたはサブスクリプションにデプロイする必要があります。

環境ごとに個別のワークロード ID を使用する必要があります。 各ワークロードに、デプロイに必要な最小限のアクセス許可セットを付与します。 運用環境へのデプロイのためのアクセス許可と、非運用環境へのデプロイのためのアクセス許可を混在させないように特に注意してください。

ワークロード ID のロールの割り当てを作成する

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."

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."

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) です。 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 は、人間が判読できるロールの割り当ての説明です。