Description
Binding the cluster-admin role with kubernetes_cluster_role_binding grants the subject extensive permissions throughout the cluster. Because cluster-admin provides superuser access, use it only when necessary.
These permissions can affect all namespaces and resources. An inappropriate grant can turn a problem with one user or service account into a cluster-wide risk.
Potential impact
- A user or service account can control the entire cluster.
- Misuse or compromise of the account can greatly increase the scope of damage.
Remediation
- Restrict
cluster-adminto identities that need it. Use a Role or ClusterRole containing only necessary permissions and a binding with the appropriate scope for ordinary tasks. - Review administrator grants regularly. Changing role_ref requires replacing the binding, so preserve a working administrative access path during the transition.
Examples
The after name cluster does not identify a built-in restricted role. Define that ClusterRole separately and review its actual rules. Renaming the reference alone does not ensure least privilege.
Before
hcl
resource "kubernetes_cluster_role_binding" "example" {
metadata {
name = "terraform-example"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "ClusterRole"
name = "cluster-admin"
}
subject {
kind = "User"
name = "admin"
api_group = "rbac.authorization.k8s.io"
}
}
After
hcl
resource "kubernetes_cluster_role_binding" "example" {
metadata {
name = "terraform-example"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "ClusterRole"
name = "cluster"
}
subject {
kind = "User"
name = "admin"
api_group = "rbac.authorization.k8s.io"
}
}
Explanation:
- Before: The admin user receives cluster-admin permissions throughout the cluster.
- After: The binding refers to a ClusterRole named cluster. That role must contain only the required permissions.