06. Entra ID と RBAC
Azure の認可は 「Microsoft Entra ID(旧 Azure AD)の Principal」 に 「ロール」 を 「スコープ」 で割り当てる、の 3 点セット。AWS IAM とは設計思想が違います。
この章の目次
登場人物
| 用語 | 意味 | AWS 対応 |
|---|---|---|
| Principal | 権限を持つ対象(ユーザー、グループ、アプリ、Managed Identity) | IAM User / Role |
| Role | 許可するアクションの集合 | IAM Policy |
| Scope | 権限が適用される範囲 | Resource ARN |
| Role Assignment | Principal × Role × Scope の組 | IAM Policy Attachment |
スコープの階層
Management Group ← 複数 Subscription をまたぐ統制
└── Subscription
└── Resource Group
└── Resource (個別)
上位スコープで付けた権限は下位スコープにも継承されます。「Subscription 全体に Reader」を付ければ、全 RG・全リソースの読み取りが可能。
role_assignment の基本
data "azurerm_subscription" "current" {}
data "azuread_user" "alice" {
user_principal_name = "alice@example.com"
}
# サブスクリプション全体にロール付与
resource "azurerm_role_assignment" "alice_reader" {
scope = data.azurerm_subscription.current.id
role_definition_name = "Reader"
principal_id = data.azuread_user.alice.object_id
}
# 特定の Storage Account への書き込み
resource "azurerm_role_assignment" "vm_to_blob" {
scope = azurerm_storage_account.data.id
role_definition_name = "Storage Blob Data Contributor"
principal_id = azurerm_linux_virtual_machine.web.identity[0].principal_id
}
よく使う組み込みロール
| ロール | 用途 |
|---|---|
| Owner | すべて + 他人への権限付与 |
| Contributor | リソース作成・編集・削除(IAM 付与は不可) |
| Reader | 閲覧のみ |
| User Access Administrator | IAM 付与だけできる |
| Storage Blob Data Contributor | Blob の読み書き |
| Storage Blob Data Reader | Blob の読み取り |
| Key Vault Secrets User | シークレットの取得 |
| Key Vault Administrator | Key Vault 内すべての操作 |
| AcrPull | Container Registry から pull |
カスタムロール
resource "azurerm_role_definition" "myapp_deployer" {
name = "myapp-deployer"
scope = data.azurerm_subscription.current.id
description = "Deploy myapp resources only"
permissions {
actions = [
"Microsoft.ContainerRegistry/registries/push/write",
"Microsoft.App/containerApps/read",
"Microsoft.App/containerApps/write",
]
not_actions = [
"Microsoft.App/containerApps/delete", # 削除は禁止
]
}
assignable_scopes = [data.azurerm_subscription.current.id]
}
Managed Identity との連携
Managed Identity は「リソース自身の ID」。04 章でも触れた通り、VM や App Service が他 Azure サービスを叩く時の認証方式。
# Container App 用 User-Assigned Managed Identity
resource "azurerm_user_assigned_identity" "app" {
name = "id-myapp-prd"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
}
# この MI に Key Vault Secrets User を付与
resource "azurerm_role_assignment" "app_kv" {
scope = azurerm_key_vault.main.id
role_definition_name = "Key Vault Secrets User"
principal_id = azurerm_user_assigned_identity.app.principal_id
}
# Container App から MI を使う
resource "azurerm_container_app" "main" {
# ...
identity {
type = "UserAssigned"
identity_ids = [azurerm_user_assigned_identity.app.id]
}
}
Service Principal の作成
古い方式だが、外部 CI などで Managed Identity を使えない時に。
resource "azuread_application" "ci" {
display_name = "ci-myapp"
}
resource "azuread_service_principal" "ci" {
client_id = azuread_application.ci.client_id
}
resource "azuread_service_principal_password" "ci" {
service_principal_id = azuread_service_principal.ci.id
end_date = "2027-12-31T23:59:59Z"
}
resource "azurerm_role_assignment" "ci_contributor" {
scope = data.azurerm_subscription.current.id
role_definition_name = "Contributor"
principal_id = azuread_service_principal.ci.object_id
}
パスワード方式は避けたい
Service Principal にパスワード(secret)を持たせる代わりに、OIDC フェデレーション(01 章)が推奨。シークレット流出のリスクがゼロになる。