Day 65: RBAC and ServiceAccounts
Who can do what to which resources
RBAC (Role-Based Access Control) governs every request to the API server. A Role (namespace-scoped) or ClusterRole (cluster-wide) lists allowed verbs (get, list, create, delete...) on resources (pods, secrets...); a RoleBinding/ClusterRoleBinding grants that role to a user, group, or ServiceAccount.
A ServiceAccount is an identity for a *process* (a Pod), not a human — every Pod runs as a ServiceAccount (the default one, if none is specified), and whatever that ServiceAccount is bound to via RBAC determines what the Pod's own code can do against the API server if it uses a Kubernetes client library.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: ['']
resources: ['pods']
verbs: ['get', 'list']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: monitoring-agent
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioThe default ServiceAccount is over-permissioned by habit, not by need
It's extremely common to see every Pod in a namespace silently running as the default ServiceAccount with no explicit RBAC thought given to it. Least privilege here means: give each workload its own ServiceAccount, bound only to the specific Role it actually needs.
Key terms
- Role / ClusterRole
- Defines allowed verbs on resources, scoped to a namespace or cluster-wide.
- RoleBinding / ClusterRoleBinding
- Grants a Role to a user, group, or ServiceAccount.
- ServiceAccount
- An identity used by a Pod/process, distinct from a human user identity.
A compromised Pod running as the default ServiceAccount with cluster-admin bound to it could do what?
