説明
同じ名前空間で同一の ServiceAccount を使うワークロードは、API 上の主体とアカウントに付与された権限を共有します。ただし、現在の Pod にバインドされたトークンは Pod ごとに発行できるため、同じアカウントでもトークン値まで常に同じとは限りません。
用途や権限要件が異なるワークロードはアカウントを分けてください。同じアプリケーションのレプリカなど、同じ権限を意図的に共有する構成は要件に応じて利用できます。
想定される影響
- あるワークロードに必要な広い権限が、同じアカウントを使う他のワークロードにも付与される場合があります。
- 共有する主体からの呼び出しは、監査記録でワークロードを区別しにくくする場合があります。
対処方法
- 用途や権限要件が異なるワークロードには、別の ServiceAccount を使ってください。各アカウントの RoleBinding と実際に許可される操作を確認してください。
- Pod が使うアカウントを明示し、API トークンが不要なら自動マウントを無効にしてください。同じアカウントを使う全 Pod を考慮し、権限変更やトークン事故への対応を計画してください。
例
各例には Pod を一つだけ示しています。最初のアカウントを他のワークロードも使う状況を想定した比較で、このコードだけで共有を断定することはできません。アカウントを先に用意し、実際のデプロイには保守されているイメージを使ってください。
変更前
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "with-pod-affinity"
}
spec {
container {
name = "with-pod-affinity"
image = "k8s.gcr.io/pause:2.0"
}
service_account_name = "terraform-example"
}
}
resource "kubernetes_service_account" "shared" {
metadata {
name = "terraform-example"
}
}
変更後
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "with-pod-affinity-2"
}
spec {
container {
name = "with-pod-affinity"
image = "k8s.gcr.io/pause:2.0"
}
service_account_name = "service-name"
}
}
resource "kubernetes_service_account" "dedicated" {
metadata {
name = "service-name"
}
}
補足:
- 変更前: terraform-example アカウントを使います。別の用途のワークロードも同じアカウントを使うか、実際の構成を確認してください。
- 変更後: 専用の service-name アカウントを使います。実際の権限も制限する必要があります。