CKA · Question #35
Context: You have been asked to create a new ClusterRole for a deployment pipeline and bind it to a specific ServiceAccount scoped to a specific namespace. Task: Create a new ClusterRole named deploym
Kubernetes RBAC: ClusterRole + ServiceAccount + RoleBinding Overall Goal This task configures Role-Based Access Control (RBAC) for a CI/CD pipeline. The pipeline needs to deploy workloads (Deployments, StatefulSets, DaemonSets) but should have no more access than necessary - a co
Question
Explanation
Kubernetes RBAC: ClusterRole + ServiceAccount + RoleBinding
Overall Goal
This task configures Role-Based Access Control (RBAC) for a CI/CD pipeline. The pipeline needs to deploy workloads (Deployments, StatefulSets, DaemonSets) but should have no more access than necessary - a core security principle called least privilege.
The key design choice: use a ClusterRole (cluster-wide definition of permissions) but bind it with a RoleBinding scoped to one namespace. This avoids duplicating the role definition across namespaces while still confining the actual access.
Step 1: Create the ClusterRole
kubectl create clusterrole deployment-clusterrole \
--verb=create \
--resource=deployments,statefulsets,daemonsets
Why: A ClusterRole defines what actions are allowed on what resources. It lives at the cluster level (no namespace), making it reusable across namespaces. You only grant create - not get, list, delete, or update - so the pipeline can deploy but cannot read secrets, delete workloads, or do anything else.
If skipped: Nothing can be bound. The subsequent binding step would fail referencing a non-existent role.
Step 2: Create the ServiceAccount
kubectl create serviceaccount cicd-token -n app-team1
Why: A ServiceAccount is the identity the pipeline process runs as inside Kubernetes. It must exist in the target namespace (app-team1) because that's where the pipeline's pods will run and where the binding will be scoped.
If skipped: The RoleBinding would reference a non-existent subject, and the pipeline would have no valid identity to authenticate with.
Step 3: Create the RoleBinding (not ClusterRoleBinding)
kubectl create rolebinding cicd-token-binding \
--clusterrole=deployment-clusterrole \
--serviceaccount=app-team1:cicd-token \
-n app-team1
Why this is a RoleBinding, not a ClusterRoleBinding: This is the critical distinction. A RoleBinding in namespace app-team1 grants the ClusterRole's permissions only within that namespace. A ClusterRoleBinding would grant those permissions cluster-wide - a massive security mistake for a pipeline that should only deploy to one team's namespace.
The --serviceaccount format is namespace:name - required to identify the account unambiguously across the cluster.
If done out of order: Order doesn't cause API failures here, but creating the binding before the ClusterRole or ServiceAccount exist will fail because Kubernetes validates the referenced subjects and roles.
Common Mistakes
| Mistake | Consequence |
|---|---|
Using ClusterRoleBinding instead of RoleBinding | Pipeline can deploy to every namespace |
Granting * verbs | Pipeline can delete, update, or read workloads |
| Wrong namespace on ServiceAccount | Binding references a non-existent subject |
Memory Tip
"Define → Identity → Bind (scoped)"
- Define what's allowed (ClusterRole)
- Identity to act as (ServiceAccount in the right namespace)
- Bind them together - and the type of binding controls the scope:
RoleBinding= namespace-local,ClusterRoleBinding= cluster-wide
Think of it like a job description (ClusterRole), an employee badge (ServiceAccount), and an access card that only works on one floor (RoleBinding in one namespace).
Topics
Community Discussion
No community discussion yet for this question.