説明
AKS がサービスプリンシパルで Azure リソースへアクセスする場合、その認証情報を保護し、ローテーションする必要があります。マネージド ID では Azure が認証情報を管理するため負担を減らせますが、必要な権限だけを付与する作業は引き続き必要です。
想定される影響
- サービスプリンシパルのシークレット漏えいや更新漏れが、リソースへのアクセスやサービス運用に影響する場合があります。
- クラスターや kubelet のロールが過剰だと、マネージド ID を使っていても被害範囲が広がる場合があります。
対処方法
- 用途に合う
identityブロックを設定し、SystemAssigned または承認された UserAssigned ID を選んでください。クラスターと kubelet の Azure RBAC ロールを個別に最小限にしてください。 - サービスプリンシパルから移行する際は、リソース権限とノードプールの移行手順を確認してください。新しい ID で実際の処理を確認した後、不要になった認証情報を整理してください。
例
ID 設定を比較する抜粋です。変更前はマネージド ID とサービスプリンシパルの両方を省略しており、完全なデプロイ構成ではありません。AzureRM はどちらかを要求します。
変更前
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
}
変更後
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
identity {
type = "SystemAssigned"
}
}
補足:
- 変更前: この抜粋にはクラスターの認証 ID が定義されていません。
- 変更後: システム割り当てマネージド ID を選びます。必要なリソース権限は別途付与してください。