Kubernetes RBAC basics: least-privilege access for a service account

Role-based access control (RBAC) decides whether a request to the API server is allowed. Permissions are purely additive: there are no deny rules, so anything not explicitly allowed is refused.

The four objects

• Role: a list of rules (API groups, resources, verbs) that applies inside one namespace.
• ClusterRole: the same, but cluster-wide, or reusable in many namespaces. Also needed for cluster-scoped resources such as nodes.
• RoleBinding: grants a Role or a ClusterRole to subjects (users, groups, service accounts) within one namespace.
• ClusterRoleBinding: grants a ClusterRole across the whole cluster. Use sparingly.

Subjects come in three kinds. Users and groups come from your authentication setup (certificates, OIDC); Kubernetes has no user objects. Service accounts are namespaced objects meant for software, and their username has the form system:serviceaccount:<namespace>:<name>.

Step 1: create a service account

kubectl create serviceaccount ci-deployer -n shop

Step 2: define a Role with only what is needed

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: shop
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

apiGroups: [""] is the core group (Pods, Services, ConfigMaps, Secrets). Subresources such as logs are named resource/subresource. This Role deliberately leaves out Secrets and delete.

Step 3: bind it

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer
  namespace: shop
subjects:
- kind: ServiceAccount
  name: ci-deployer
  namespace: shop
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: deployer

kubectl apply -f role.yaml -f rolebinding.yaml

You cannot change the roleRef of an existing binding; delete and recreate the binding instead. For quick grants, kubectl can create bindings to the built-in ClusterRoles view, edit and admin, which then apply only inside the binding’s namespace:

kubectl create rolebinding ci-view --clusterrole=view --serviceaccount=shop:ci-deployer --namespace=shop

Step 4: verify with kubectl auth can-i

kubectl auth can-i patch deployments -n shop --as=system:serviceaccount:shop:ci-deployer
kubectl auth can-i get secrets -n shop --as=system:serviceaccount:shop:ci-deployer
kubectl auth can-i delete deployments -n shop --as=system:serviceaccount:shop:ci-deployer
kubectl auth can-i --list -n shop --as=system:serviceaccount:shop:ci-deployer

The first should print yes and the others no. Impersonation with --as itself requires permission, which cluster administrators normally have.

Traps to avoid

• Anyone who can create Pods in a namespace can mount any Secret and service account token in it. Treat create pods (and create on Deployments, Jobs and similar) as close to get secrets.
• The escalate, bind and impersonate verbs and wildcards (*) let a subject give itself more rights. Do not grant them to automation.
• Avoid ClusterRoleBindings to cluster-admin for applications or CI. Bind namespaced Roles instead.
• Workloads that do not call the API should not get a token: set automountServiceAccountToken: false in the Pod spec or on the service account.

When a request is denied, the API server answers with a Forbidden error naming the user, verb, resource and namespace. Feed exactly those values into kubectl auth can-i to confirm the fix.

Official documentation

• Using RBAC Authorization
• kubectl auth can-i