Kubernetes RBAC: bind one service account to one job

Last updated: 7 Oct 20266 min read

tutorial

Role-based access control authorizes Kubernetes API actions through Roles or ClusterRoles and their bindings. A RoleBinding grants permissions within one namespace. A workload normally runs under a ServiceAccount; granting broad access to the namespace's default account can make that authority available to unrelated Pods.

Operational decision

A release observer needs to read Deployments in the operations namespace to report rollout status. Create a dedicated ServiceAccount, grant get and list on deployments there, and bind that Role only to that identity. The YAML sample contains three documents so the identity, permissions, and binding can be reviewed together. Do not add secrets read access merely to make debugging easier; secret access can expose credentials. Test the effective permission with kubectl auth can-i using service-account impersonation before running the Pod. Also inspect what the container can reach on the network, because RBAC controls Kubernetes API requests, not all network connections. If the job never calls the Kubernetes API, disable its automatic service-account token mount instead of creating a Role.

apiVersion: v1
kind: ServiceAccount
metadata: {name: rollout-observer, namespace: operations}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: {name: rollout-reader, namespace: operations}
rules:
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: {name: rollout-observer-binding, namespace: operations}
subjects:
  - {kind: ServiceAccount, name: rollout-observer, namespace: operations}
roleRef: {kind: Role, name: rollout-reader, apiGroup: rbac.authorization.k8s.io}

Cost and verification

Fine-grained roles take maintenance as APIs and workloads change, but reduce blast radius. A cluster-wide binding is easier to write and easier to misuse. Test both intended permissions and a denied operation. A service account's token may be present in a Pod even when code does not need it; remove the mount in such workloads. Review who can edit the Role, RoleBinding, and workload template, because control of those resources can change effective authority.

Common Mistakes

Do not attach cluster-admin to a service account for convenience.
Do not grant the namespace default account permissions meant for one workload.
Do not confuse API authorization with network isolation.

Connected lessons

Advanced follow-up

Break-glass access: recover control without permanent privilege

Advanced follow-up

Secret access: audit workload creation as an indirect read permission

devops

operations