説明
マネージド ID を使うと、コードや設定に長期の認証情報を直接保存せず、対応する Azure リソースにアクセスできます。個別のシークレットやキーは、設定管理と秘密情報保護の負担を増やします。他のリソースへアクセスしないアプリに、必ず ID が必要というわけではありません。
想定される影響
- コードや設定に残ったシークレットが漏えいするおそれがあります。
- 認証情報の交換や権限管理の負担が増える場合があります。
対処方法
対象サービスが対応する場合は、identity { type = "SystemAssigned" } または適切なユーザー割り当て ID を設定してください。必要な権限だけを付与し、アプリの認証を ID に切り替えてください。動作確認後に従来のシークレットを削除し、他でも不要になった認証情報は失効させてください。
例
AzureRM 3.x の従来の azurerm_app_service でシステム割り当て ID を有効にする例です。現在の Linux・Windows Web App も identity ブロックに対応しています。
変更前
hcl
resource "azurerm_app_service" "example" {
name = "example-app-service"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
}
変更後
hcl
resource "azurerm_app_service" "example" {
name = "example-app-service"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
identity {
type = "SystemAssigned"
}
}
変更後は Azure がアプリの ID を管理します。対象リソースの権限と認証コードの変更は別途必要であり、アプリへログインするユーザーの認証とも異なります。