★★ 中級

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 AssignmentPrincipal × 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 AdministratorIAM 付与だけできる
Storage Blob Data ContributorBlob の読み書き
Storage Blob Data ReaderBlob の読み取り
Key Vault Secrets Userシークレットの取得
Key Vault AdministratorKey Vault 内すべての操作
AcrPullContainer 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 章)が推奨。シークレット流出のリスクがゼロになる。