Kubernetes RBAC & Service Accounts, In Depth (Fundamentals)

Every request that reaches the Kubernetes API server — a kubectl get pods, a controller reconciling a Deployment, a pod calling the API from inside the cluster — is checked twice before anything happens: who are you? (authentication) and are you allowed to do this? (authorisation). RBAC — Role-Based Access Control — is how Kubernetes answers the second question. It is the layer that decides whether a request becomes an action or a Forbidden.

This lesson takes RBAC apart field by field. By the end you will be able to read any Role, ClusterRole, RoleBinding or ClusterRoleBinding and say exactly what it grants and to whom; you will understand ServiceAccounts and the short-lived tokens that pods now use; and you will be able to prove any permission with a single command. This is the foundational companion to the advanced Least-Privilege RBAC design lesson — here we build the mental model and cover every primitive; there we cover designing, aggregating and auditing RBAC at scale.

Learning objectives

By the end of this lesson you will be able to:

• Explain where RBAC sits in the request pipeline: authentication → authorisation → admission, and what RBAC does and does not control.
• Name the four RBAC objects and choose the right one by scope (namespaced vs cluster-wide).
• Write an RBAC rule correctly — apiGroups, resources, subresources, verbs, resourceNames, nonResourceURLs — and avoid the wildcard trap.
• Describe the three subject kinds (User, Group, ServiceAccount) and how each is authenticated.
• Create and use ServiceAccounts, understand bound/projected tokens vs legacy Secret tokens, control automounting, and attach imagePullSecrets.
• Use kubectl auth can-i (including --as, --as-group, and --list) to verify permissions as ground truth.
• Apply least-privilege patterns and recognise the common RBAC mistakes that send people reaching for cluster-admin.

Prerequisites

You need a working kubectl and a cluster you can experiment in — a free local one is perfect (kind, minikube, or k3d). It helps to have met the core objects from earlier in the course — Pods, Deployments & Services — and to be comfortable with kubectl itself (get, describe, apply). You should also understand Namespaces, because the namespaced-vs-cluster-wide distinction is the heart of RBAC. This is the Security lesson of the Kubernetes Zero-to-Hero course; everything runs on free, local tooling with no cloud account required. Targets the current API (Kubernetes v1.30+), where RBAC has been stable (rbac.authorization.k8s.io/v1) for years.

Where RBAC sits: the request pipeline

When any client talks to the API server, the request passes through three gates in order. RBAC is only the middle one — getting this picture right prevents most confusion.

Three consequences worth internalising:

1. RBAC never authenticates. It receives an already-established identity (the username/groups string) and matches it. It never checks that a user “exists” — Users and Groups are not Kubernetes objects (more in Subjects below).
2. Authorisation is a union of authorisers. On a managed cluster the Node authorizer grants kubelets exactly what they need for their own node; RBAC handles everyone else. A “yes” from any enabled authoriser wins, so RBAC can only grant, never deny over the top of another authoriser.
3. RBAC is purely additive. Within RBAC there are no deny rules. A subject’s effective permission is the union of every binding that matches them. You reduce access by removing or narrowing bindings — never by adding a denial.

If you ever see Forbidden with a clear message naming the missing verb/resource, that is the authorisation stage (RBAC). If you see admission webhook ... denied, authorisation already said yes and a later policy said no. They are different problems with different fixes.

The four RBAC objects: scope is everything

RBAC has exactly four object kinds, all in the API group rbac.authorization.k8s.io/v1. They split along two axes: permissions (Role/ClusterRole — what may be done) and bindings (RoleBinding/ClusterRoleBinding — who gets it). The dimension people trip over is scope, not function.

A Role and a ClusterRole are inert on their own — they are just permission templates. Nothing happens until a binding ties a Role/ClusterRole to one or more subjects. A binding has two halves: a roleRef (which permission set) and a subjects list (who receives it).

Why ClusterRole exists when Role seems enough

A ClusterRole is needed for three things a namespaced Role cannot express:

• Cluster-scoped resources — nodes, persistentvolumes, namespaces, clusterroles themselves, storageclasses. These do not live in a namespace, so only a ClusterRole (bound by a ClusterRoleBinding) can grant them.
• Non-resource URLs — endpoints like /healthz, /metrics, /version, /api. These are not REST resources; you grant them with nonResourceURLs, which only a ClusterRole supports.
• A reusable permission set across many namespaces — author the rules once as a ClusterRole, then grant them per namespace with a RoleBinding. This is the single most important RBAC pattern (see below).

The combination that surprises everyone

A RoleBinding can reference either a Role or a ClusterRole. When a RoleBinding references a ClusterRole, the subject gets those permissions only in the binding’s namespace — the cluster-wide reach of the ClusterRole is clipped to that one namespace.

This table is the most exam-tested fact in RBAC. The workhorse is the bottom-left cell: one ClusterRole named app-developer, bound by a RoleBinding in each tenant namespace — reusable, yet scoped.

# One reusable permission set...
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: app-developer
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services", "configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
# ...scoped to exactly one namespace by a RoleBinding referencing it
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-developers
  namespace: team-a            # grant applies ONLY here
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole            # reference the cluster role...
  name: app-developer
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "eng-team-a"         # ...for this group, in this namespace only

roleRef is immutable. Once a binding is created you cannot change which Role/ClusterRole it points at — you must delete and recreate it. The subjects list, by contrast, can be edited freely.

The anatomy of a rule, field by field

The permission lives inside the rules list of a Role or ClusterRole. A rule is, conceptually, apiGroups × resources × verbs, optionally narrowed by resourceNames, with subresources addressed via resources. This is where exhaustiveness matters, so here is every field.

The verbs, exhaustively

Verbs map to HTTP methods against the API. Memorise these — they are the vocabulary of every rule.

Plus special, non-CRUD verbs that are real escalation paths — covered in Security notes:

A crucial subtlety: get does not imply list. They are independent verbs against different endpoints. A role with only get lets you read a pod if you already know its name, but kubectl get pods (which lists) will return Forbidden. Grant ["get","list","watch"] together for normal read access. Likewise, list returns full objects — there is no “list names only”, so anyone with list secrets can read secret values.

Worked rule: every field in play

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payments-operator
  namespace: team-payments
rules:
  # Full lifecycle on deployments in this namespace
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  # Scale subresource is a SEPARATE grant
  - apiGroups: ["apps"]
    resources: ["deployments/scale"]
    verbs: ["update", "patch"]
  # Read pod logs (subresource), but not exec
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  # Read EXACTLY one configmap by name, nothing else
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["payments-feature-flags"]
    verbs: ["get", "update", "patch"]

Read it as four independent grants OR’d together. Note that pods/log (read logs) and pods/exec (shell in) are different subresources — granting one never grants the other.

Subjects: who a binding grants to

The subjects list of a binding holds one or more of three kinds. Each is authenticated differently before RBAC ever sees it.

Two facts that catch people out:

• Users and Groups are not created in Kubernetes. There is no kubectl create user. The API server trusts whatever username/groups your authenticator produces; RBAC simply matches the string. So a binding to User: alice@corp.com works the moment Alice authenticates as that string — even if nobody “made” Alice.
• ServiceAccounts are the only subject kind that is a real, namespaced object, which is why they have name + namespace and apiGroup: "".

The full SA username form, which you use with impersonation and in some bindings, is:

system:serviceaccount:<namespace>:<name>

And every SA automatically belongs to two groups: system:serviceaccounts (all SAs) and system:serviceaccounts:<namespace> (all SAs in that namespace).

Built-in users and groups you’ll meet

Default ClusterRoles: don’t reinvent these

Kubernetes ships default (built-in) ClusterRoles so you rarely write read/write roles from scratch. The four “user-facing” ones are the ones to know.

These built-ins are aggregated (they absorb labelled add-on ClusterRoles automatically) — a powerful but double-edged feature covered in the advanced RBAC lesson. For most teams the pattern is: bind view/edit/admin with a RoleBinding per namespace, and reserve cluster-admin for emergencies.

Never bind cluster-admin with a ClusterRoleBinding to a person or a workload SA “to make the error go away”. The whole point of RBAC is least privilege; cluster-admin discards it.

ServiceAccounts: identity for workloads

A User is for humans; a ServiceAccount (SA) is for workloads. Every pod runs as exactly one SA, and that SA is how the pod authenticates to the API server (and how RBAC decides what the pod may do).

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-processor
  namespace: team-payments
automountServiceAccountToken: false   # see "automounting" below

A pod selects its SA with spec.serviceAccountName. If you omit it, the pod uses the namespace’s default SA.

apiVersion: apps/v1
kind: Deployment
metadata: { name: order-processor, namespace: team-payments }
spec:
  template:
    spec:
      serviceAccountName: order-processor   # else "default" is used
      containers:
        - name: app
          image: ghcr.io/acme/orders:1.4.0

The default ServiceAccount

Every namespace gets a default SA automatically (created by a controller). Two important points:

• The default SA has no RBAC permissions of its own — out of the box it cannot do anything against the API. (Its token is still a valid identity, which matters for system:serviceaccounts group bindings, but it carries no granted verbs by default.)
• Best practice: never bind permissions to default, and give each workload its own SA. Binding to default grants those permissions to every pod in the namespace that didn’t pick a different SA — a broad, accidental blast radius.

Tokens: bound/projected vs the legacy Secret token

How a pod actually authenticates is the part that changed most in modern Kubernetes. There are three eras; know all three because you’ll meet old manifests.

Inside a pod, the projected token (and CA cert + namespace) lands at:

/var/run/secrets/kubernetes.io/serviceaccount/token
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
/var/run/secrets/kubernetes.io/serviceaccount/namespace

To mint a token from the command line (for testing or short-lived automation), use the TokenRequest API directly:

# Short-lived token for an SA (audience = API server by default)
kubectl create token order-processor -n team-payments

# With a custom expiry and audience
kubectl create token order-processor -n team-payments \
  --duration=30m --audience=https://kubernetes.default.svc

kubectl create token is the modern replacement for the old trick of reading a long-lived token out of a Secret. Prefer it everywhere. If you truly need a non-expiring token (rare — e.g. an external CI system that can’t refresh), you must create the Secret explicitly; do so knowing you’ve created a static credential to guard and rotate.

Automounting the token

By default, the SA token is mounted into every pod — handy if the workload calls the API, but a needless credential for one that doesn’t (a web frontend that only serves HTTP has no reason to hold a cluster token). Anyone who lands code execution in that container gets a ready-made credential.

Control it at two levels (pod-level wins if both are set):

# On the ServiceAccount: default for all pods using this SA
apiVersion: v1
kind: ServiceAccount
metadata: { name: web-frontend, namespace: shop }
automountServiceAccountToken: false
---
# On the Pod: overrides the SA setting for this pod
apiVersion: apps/v1
kind: Deployment
metadata: { name: web-frontend, namespace: shop }
spec:
  template:
    spec:
      serviceAccountName: web-frontend
      automountServiceAccountToken: false   # belt-and-braces

Rule of thumb: default to false, and switch it on only for workloads that genuinely talk to the API.

imagePullSecrets on a ServiceAccount

A ServiceAccount can also carry image pull credentials so pods using it can pull from a private registry without each pod specifying the secret. First create a docker-registry secret, then attach it to the SA:

kubectl create secret docker-registry regcred \
  --docker-server=ghcr.io \
  --docker-username=acme-bot \
  --docker-password='<token>' \
  -n team-payments

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-processor
  namespace: team-payments
imagePullSecrets:
  - name: regcred        # every pod using this SA inherits this pull credential

Now any pod with serviceAccountName: order-processor can pull private images without its own imagePullSecrets. (Note imagePullSecrets is a list of {name} objects; it references docker-registry secrets, not RBAC.)

The RBAC model at a glance

The diagram traces a request from a subject (a User, Group, or a pod’s ServiceAccount) through a binding (RoleBinding for one namespace, or ClusterRoleBinding cluster-wide) to a permission set (Role inside a namespace, or ClusterRole spanning the cluster), where the matching rule — apiGroups × resources × verbs — is what finally allows or forbids the action at the API server. Read it left to right: who → via which binding → gets which rules → over which resources.

Hands-on lab: build and test RBAC end to end

Everything here runs on a free local cluster and is fully reversible. We will create a namespace, a ServiceAccount, a least-privilege Role, bind it, mint a token, and prove the boundaries with kubectl auth can-i.

0. Start a cluster

kind create cluster --name rbac-lab        # or: minikube start  / k3d cluster create
kubectl cluster-info

1. Namespace and ServiceAccount

kubectl create namespace team-payments
kubectl create serviceaccount ci-deployer -n team-payments

2. A least-privilege Role and a RoleBinding

Save as rbac-lab.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: team-payments
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  # Deliberately NO secrets, NO pods/exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer-binding
  namespace: team-payments
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: deployer
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: team-payments

kubectl apply -f rbac-lab.yaml

Expected:

role.rbac.authorization.k8s.io/deployer created
rolebinding.rbac.authorization.k8s.io/ci-deployer-binding created

3. Prove the permissions with auth can-i (impersonation)

kubectl auth can-i asks the real authoriser, so it is ground truth. Impersonate the SA with --as:

# Should be ALLOWED
kubectl auth can-i create deployments -n team-payments \
  --as=system:serviceaccount:team-payments:ci-deployer        # -> yes

kubectl auth can-i get pods -n team-payments \
  --as=system:serviceaccount:team-payments:ci-deployer        # -> yes

# Should be FORBIDDEN (we never granted these)
kubectl auth can-i get secrets -n team-payments \
  --as=system:serviceaccount:team-payments:ci-deployer        # -> no

kubectl auth can-i create pods/exec -n team-payments \
  --as=system:serviceaccount:team-payments:ci-deployer        # -> no

# Wrong namespace -> the Role doesn't reach there
kubectl auth can-i create deployments -n default \
  --as=system:serviceaccount:team-payments:ci-deployer        # -> no

List everything the SA can do in the namespace:

kubectl auth can-i --list -n team-payments \
  --as=system:serviceaccount:team-payments:ci-deployer

Impersonation itself is a privileged action. As the cluster-admin in your kubeconfig you can --as anyone; a normal user needs the impersonate verb. That’s why auth can-i --as works for you here without extra setup.

4. Mint a real token and call the API as the SA

TOKEN=$(kubectl create token ci-deployer -n team-payments --duration=10m)

# Use the token directly against the API server
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
curl -sk -H "Authorization: Bearer $TOKEN" \
  "$APISERVER/apis/apps/v1/namespaces/team-payments/deployments" | head

# Same token trying secrets -> 403 Forbidden body
curl -sk -H "Authorization: Bearer $TOKEN" \
  "$APISERVER/api/v1/namespaces/team-payments/secrets"

The first call returns a deployment list (or an empty list); the second returns a 403 Forbidden status object — RBAC enforcing exactly what you bound.

5. Validation

kubectl describe rolebinding ci-deployer-binding -n team-payments
kubectl get role deployer -n team-payments -o yaml

You should see the binding’s roleRef → deployer and the single SA subject.

6. Cleanup

kubectl delete -f rbac-lab.yaml
kubectl delete serviceaccount ci-deployer -n team-payments
kubectl delete namespace team-payments
kind delete cluster --name rbac-lab        # or: minikube delete / k3d cluster delete

Cost note: zero — everything is local. No cloud account, no charges.

Common mistakes & troubleshooting

The fastest debugging loop is always: reproduce the exact decision with kubectl auth can-i <verb> <resource> -n <ns> --as=<subject>, then add the specific missing verb/resource to a scoped Role — never widen to cluster-admin.

Best practices

• Author permission sets once as a ClusterRole, scope them per namespace with a RoleBinding. This is the canonical reusable pattern.
• Prefer the built-in view/edit/admin ClusterRoles bound per namespace before writing custom roles.
• Enumerate apiGroups, resources, and verbs explicitly. Avoid * — a wildcard silently absorbs future API types, including CRDs.
• Give every workload its own ServiceAccount. Never bind anything to the default SA, and never reuse one SA across unrelated workloads.
• Set automountServiceAccountToken: false by default, enabling it only for workloads that call the API.
• Bind to Groups, not individuals (wire OIDC and bind the IdP group) so access lives in your identity provider with an audit trail — see the advanced lesson.
• Keep all Roles/Bindings in Git, reviewed and reconciled, so every permission change is peer-reviewed and reversible.
• Verify with kubectl auth can-i after every change — assert both the can and the cannot.

Security notes

RBAC is a primary security boundary, so a few risks deserve emphasis even at the fundamentals level:

• list/get on secrets is read access to secret values (they’re base64, not encrypted). A “read-only” role that includes secrets can read every mounted SA token in the namespace and then impersonate those SAs. Exclude secrets from broad read roles; grant specific secrets by resourceNames only.
• pods/exec and pods/attach inherit the target pod’s identity — granting them is granting whatever that pod can do. Keep exec on its own, tightly bound role and audit it.
• escalate, bind, and impersonate are super-powers. escalate/bind let a subject grant themselves more than they hold (bypassing the built-in escalation check); impersonate lets them become anyone. Treat create on clusterroles/rolebindings as privileged too.
• create on pods plus a privileged SA in the namespace lets a subject launch a pod that mounts that SA’s token (or a hostPath/privileged pod) — an indirect escalation. Scope pod-creation carefully in shared namespaces.
• The mounted SA token is a credential. Disable automount where unused; prefer short-lived bound tokens over static Secret tokens; never paste tokens or kubectl get secret -o yaml output into logs or tickets.
• system:masters and cluster-admin are the keys to the kingdom. Keep exactly one audited break-glass path and alert on any new binding to either.

These threads are developed fully in Least-Privilege RBAC design (aggregation footguns, escalation-path hunting, continuous auditing) and in Pod Security Admission.

Interview & exam questions

1. What is the difference between authentication and authorisation in Kubernetes, and where does RBAC sit? Authentication establishes who you are (cert/OIDC/token → username + groups) and fails with 401. Authorisation decides whether you may act and fails with 403. RBAC is an authoriser in the authorisation stage; admission control runs after, and is a separate concern.

2. Role vs ClusterRole — when must you use a ClusterRole? Use a ClusterRole for cluster-scoped resources (nodes, PVs, namespaces, the RBAC objects themselves), for non-resource URLs (/healthz, /metrics), or to define a reusable permission set you’ll bind per namespace.

3. A RoleBinding references a ClusterRole. What does the subject get? Only the permissions of that ClusterRole within the binding’s namespace — the cluster-wide reach is clipped to that one namespace. This is the workhorse multi-tenant pattern.

4. Can a ClusterRoleBinding reference a Role? No. A ClusterRoleBinding can only reference a ClusterRole. A namespaced Role can only be referenced by a RoleBinding.

5. What are the components of an RBAC rule? apiGroups × resources × verbs, optionally narrowed by resourceNames, or nonResourceURLs (+ verbs) for non-resource endpoints. The core group is the empty string "".

6. Does get imply list? No. They are separate verbs on different endpoints. get reads one named object; list reads a collection. kubectl get <type> needs list.

7. Is RBAC additive, and can you write a deny rule? RBAC is purely additive — effective permission is the union of all matching bindings. There are no deny rules; you reduce access only by removing/narrowing bindings.

8. What is the default ServiceAccount and what can it do? Every namespace has a default SA, used by any pod that doesn’t name another. It has no RBAC permissions by default. Best practice: give workloads their own SA and never bind to default.

9. How do modern pods authenticate to the API server, and how did this change in v1.24? Via short-lived, audience-scoped bound/projected tokens from the TokenRequest API, auto-rotated by the kubelet. Before v1.24, the SA controller auto-created a non-expiring service-account-token Secret; that auto-creation was removed in v1.24.

10. How do you mint a token for a ServiceAccount from the CLI, and why prefer it? kubectl create token <sa> -n <ns> [--duration --audience]. It returns a short-lived bound token instead of a static secret, so there’s no long-lived credential to leak.

11. What does automountServiceAccountToken: false do and when should you set it? It stops the SA token from being mounted into the pod. Default it to false; enable it only for workloads that actually call the API, reducing the credential blast radius if a container is compromised.

12. Name three RBAC verbs/permissions that are privilege-escalation paths. escalate and bind on roles/clusterroles (grant yourself more than you hold / bind a high-priv role), and impersonate on users/groups/serviceaccounts (become another subject). list/get on secrets is an underrated one too.

Quick check

1. Which API group string covers pods, services, configmaps and secrets?
2. You created a Role + RoleBinding in default, but your workload runs in team-a and gets Forbidden. Why?
3. True or false: a RoleBinding can reference a ClusterRole.
4. Where does a pod’s projected ServiceAccount token appear inside the container?
5. Which command proves, as ground truth, whether a specific subject may delete secrets in team-a?

Answers

1. The core group — the empty string "".
2. A Role/RoleBinding only grant in their own namespace. They must live in team-a (or be a ClusterRole bound via a RoleBinding in team-a).
3. True. The subject then gets that ClusterRole’s permissions only in the binding’s namespace.
4. /var/run/secrets/kubernetes.io/serviceaccount/token (alongside ca.crt and namespace).
5. kubectl auth can-i delete secrets -n team-a --as=<subject> (e.g. --as=system:serviceaccount:team-a:ci).

Exercise

In a fresh local cluster, build a read-only auditor and a scoped operator, then prove the boundaries:

1. Create namespace shop and two ServiceAccounts: auditor and operator.
2. Bind auditor to the built-in view ClusterRole using a RoleBinding scoped to shop (not a ClusterRoleBinding).
3. Write a custom Role deploy-manager granting full lifecycle on deployments and deployments/scale, plus read on pods/pods/log, and bind it to operator.
4. Using kubectl auth can-i --as, assert: auditor can list pods but cannot create deployments and cannot get secrets; operator can patch deployments and update deployments/scale but cannot get secrets or create pods/exec.
5. Mint a 5-minute token for operator with kubectl create token and confirm it can list deployments but is 403 on secrets via curl.
6. Set automountServiceAccountToken: false on the auditor SA and verify a pod using it has no token file mounted.
7. Clean everything up.

Bonus: try to bind operator to a Role via a ClusterRoleBinding and observe the rejection — then explain why.

Certification mapping

Glossary

• RBAC — Role-Based Access Control; the API server’s authorisation mechanism.
• Authentication — establishing identity (username + groups); fails with 401.
• Authorisation — deciding whether an identity may perform an action; fails with 403.
• Role — a namespaced set of permission rules.
• ClusterRole — a cluster-scoped set of rules; can grant cluster-scoped resources and non-resource URLs, or be bound per namespace.
• RoleBinding — links subjects to a Role or ClusterRole, granting in one namespace.
• ClusterRoleBinding — links subjects to a ClusterRole, granting cluster-wide.
• Rule — apiGroups × resources × verbs, optionally narrowed by resourceNames, or nonResourceURLs.
• Verb — an action: get, list, watch, create, update, patch, delete, deletecollection, plus special verbs (bind, escalate, impersonate, …).
• Subject — who a binding grants to: User, Group, or ServiceAccount.
• ServiceAccount (SA) — a namespaced identity for workloads; the only subject kind that is a real object.
• default SA — the per-namespace SA used by pods that don’t name another; has no permissions by default.
• Bound / projected token — a short-lived, audience-scoped, auto-rotated SA token (TokenRequest API); the modern default.
• automountServiceAccountToken — whether the SA token is mounted into a pod.
• imagePullSecrets — registry credentials attached to an SA so its pods can pull private images.
• system:masters — the super-group bound to cluster-admin.
• Aggregation — ClusterRoles that absorb the rules of labelled add-on ClusterRoles (covered in the advanced lesson).

Next steps

• Go deeper: Designing Least-Privilege RBAC: Roles, Aggregation & Auditing at Scale — the advanced companion: reusable patterns, ClusterRole aggregation footguns, OIDC group binding, escalation-path hunting, and continuous auditing.
• Previous lesson: Kubernetes Ingress, In Depth: Controllers, Rules, TLS & the Gateway API.
• Next lesson: Kubernetes Jobs, CronJobs & DaemonSets, In Depth.
• Related: ConfigMaps & Secrets, In Depth (RBAC for secrets) and Pod Security Admission (the pod-level hardening that pairs with RBAC).