← Back to blog
RBACSecurityForbiddenCKAD
RBAC Forbidden: It Is a Permission Boundary, Not a Bug
Error from server (Forbidden) means Kubernetes enforced a rule — use auth can-i, then fix RoleBindings instead of reaching for cluster-admin.
1 min read
Your CI pipeline fails:
Error from server (Forbidden): deployments.apps is forbidden:
User "system:serviceaccount:ci:deployer" cannot create resource "deployments"The cluster is working. RBAC is working. The identity lacks permission.
Verify before you fix
kubectl auth can-i create deployments \
--as=system:serviceaccount:ci:deployer -n stagingnoNow inspect bindings:
kubectl get rolebinding,clusterrolebinding -n staging | grep deployer
kubectl describe rolebinding deployer-edit -n stagingScope matters
| Object | Grants |
|---|---|
| **Role** + RoleBinding | Namespaced verbs |
| **ClusterRole** + RoleBinding | Cluster permissions in one namespace |
| **ClusterRole** + ClusterRoleBinding | Cluster-wide |
A RoleBinding in staging does not help production. A Role without create on deployments does not help CI.
Exam and production traps
| Trap | Why |
|---|---|
| Grant **cluster-admin** to SA | Works; fails security review instantly |
| Fix Deployment YAML | Forbidden is auth, not syntax |
| Wrong namespace in `-n` | can-i passes in one ns, fails in another |
CKAD tasks often ask for minimal RBAC — create Role with exact verbs, bind to ServiceAccount.
Cross-namespace note
Secrets and ConfigMaps for volume mounts must live in the same namespace as the pod. API access to another namespace needs a RoleBinding there — mounting alone cannot cross namespaces.
Drill Security & RBAC scenarios on Decision Trainer.