説明
Container Group のコンテナーが他の Azure サービスに接続するためのアクセスキーやクライアントシークレットを保管すると、漏えいのリスクや管理負担が生じます。マネージド ID では、対応する接続の認証情報を Azure が管理します。マネージド ID がないからといって必ず固定認証情報を使っているわけではなく、実際の認証方式を確認する必要があります。
想定される影響
- コンテナーの環境変数やデプロイ状態に長期の認証情報が露出するおそれがあります。
- 漏えいした認証情報の権限で、他の Azure リソースにアクセスされるおそれがあります。
- 認証情報の交換や権限の回収が複雑になる場合があります。
対処方法
Container Group の identity ブロックに必要な SystemAssigned または UserAssigned ID を指定してください。ユーザー割り当て ID には identity_ids を設定し、接続先に最小限の権限を付与してください。コンテナーでマネージド ID のトークンを使うように変更し、接続を確認してから置き換えたシークレットを失効させてください。
例
同じ Container Group にシステム割り当てマネージド ID を追加する例です。サブネットなどの参照リソースと接続先の権限は別途構成してください。
変更前
hcl
resource "azurerm_container_group" "example" {
name = "example-continst"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
ip_address_type = "Private"
subnet_ids = [azurerm_subnet.aci.id]
os_type = "Linux"
container {
name = "app"
image = "nginx:stable"
cpu = "0.5"
memory = "1.5"
}
}
変更後
hcl
resource "azurerm_container_group" "example" {
name = "example-continst"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
ip_address_type = "Private"
subnet_ids = [azurerm_subnet.aci.id]
os_type = "Linux"
identity {
type = "SystemAssigned"
}
container {
name = "app"
image = "nginx:stable"
cpu = "0.5"
memory = "1.5"
}
}
変更後は SystemAssigned ID を使用する構成です。ネットワーク経路や接続先の権限を自動的に設定するものではないため、コンテナーからの実際の認証と接続を確認してください。