RBAC answers whether an authenticated identity may perform an API action. This lab creates a namespace-scoped read-only ServiceAccount, binds a Role, verifies allowed and denied verbs, and avoids distributing cluster-admin credentials.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
kubectl create namespace team-a
kubectl -n team-a create serviceaccount reader
kubectl auth can-i get pods --as=system:serviceaccount:team-a:reader -n team-a
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: pod-reader, namespace: team-a}
rules:
- apiGroups: ['']
resources: [pods, pods/log]
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: {name: pod-reader, namespace: team-a}
subjects:
- {kind: ServiceAccount, name: reader, namespace: team-a}
roleRef: {apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f rbac.yaml
kubectl auth can-i list pods --as=system:serviceaccount:team-a:reader -n team-a
kubectl auth can-i delete pods --as=system:serviceaccount:team-a:reader -n team-a
kubectl auth can-i --list --as=system:serviceaccount:team-a:reader -n team-a
kubectl -n team-a get role,rolebinding
4. Troubleshooting
A Role is namespace-scoped; a ClusterRole can be cluster-wide or reused in a namespace binding. Avoid wildcard verbs/resources and cluster-admin. Review impersonation results and API audit logs.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete -f rbac.yaml
kubectl delete namespace team-a
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
