説明
別のアカウントを指定していない Pod は、名前空間の default ServiceAccount を共用できます。このアカウントに Role や ClusterRole をバインドすると、それを使うワークロードが同じ権限を持ちます。対象リソースの範囲は、バインドの種類と範囲によって異なります。
権限は必要なワークロードへ狭く付与してください。用途が明確な ServiceAccount を作り、必要な Role だけをバインドしてください。
想定される影響
- 新しい Pod が既定のアカウントを使うと、不要な権限も付与される場合があります。
- 権限の共有により、悪用時の影響範囲や監査の負担が増える場合があります。
対処方法
- default ServiceAccount に付与された不要な RoleBinding と ClusterRoleBinding を削除してください。
- 用途別の ServiceAccount を作り、必要な権限だけをバインドしてください。
subjectの名前と名前空間を確認し、実際のワークロードが使うアカウントも変更してください。
例
default 名前空間の admin という Role と、kube-system の対象 ServiceAccount が別途存在する前提です。専用アカウントへの変更だけで admin Role 自体の権限が減るわけではありません。
変更前
hcl
resource "kubernetes_role_binding" "example" {
metadata {
name = "terraform-example"
namespace = "default"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = "admin"
}
subject {
kind = "ServiceAccount"
name = "default"
namespace = "kube-system"
}
}
変更後
hcl
resource "kubernetes_role_binding" "example" {
metadata {
name = "terraform-example"
namespace = "default"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = "admin"
}
subject {
kind = "ServiceAccount"
name = "service-example"
namespace = "kube-system"
}
}
補足:
- 変更前: kube-system の default ServiceAccount に、default 名前空間の Role を付与します。
- 変更後: 同じ Role の対象を専用の service-example アカウントへ変更します。