Description
A ClusterRoleBinding to cluster-admin gives its subjects nearly unrestricted permissions across the cluster. These permissions can be used to read, change and delete configuration, and to change other identities’ permissions. Production access should be limited to the actions and scope each identity needs.
Potential impact
- Compromise of one identity can affect resources across the cluster.
- Mistakes can change or delete critical resources.
Remediation
- Review the subjects and required actions of existing cluster-admin bindings. For read-only needs, use view or a custom role limited to the required resources and actions; use a RoleBinding for namespace-scoped work.
- Adding a new binding leaves existing administrative permissions in place. Because roleRef is immutable, preserve required administrator access before deliberately removing or replacing the old binding, then verify effective permissions.
Examples
These historical examples compare roles; tiller is a Helm 2 service account name. They do not recommend deploying a new Tiller installation.
Before
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
The tiller service account receives cluster-wide administrative permissions.
After
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io
A separate view-binding is added. This ClusterRoleBinding also applies view across the cluster, and the original admin-binding must be removed separately.