Give a CI pipeline least-privilege access with RBAC
Intermediate · Kubernetes · about 12 minA CI job runs as system:serviceaccount:ci:deployer. Right now it can do nothing. It needs to update Deployments and read Pods in apps, and must not read Secrets or touch other namespaces.
About this scenario
A CI job runs as system:serviceaccount:ci:deployer. Right now it can do nothing. It needs to update Deployments and read Pods in apps, and must not read Secrets or touch other namespaces.
Use --as to run kubectl as the ServiceAccount and check every permission you grant.
Objectives
- deployer can update Deployments in apps
- deployer can list Pods in apps
- deployer can't read Secrets in apps
- deployer can't touch Deployments in default
- Deploy nginx:1.29 to web as the deployer
What you'll practice
- RBAC only adds permissions. A ServiceAccount starts with none, and a RoleBinding grants a Role in its own namespace only.
- The subject's namespace and the binding's namespace can differ: ci:deployer gets rights in apps.
kubectl auth can-i ... --as=is the quickest way to test a policy before the pipeline does.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.