How does RBAC work with ServiceAccounts, and how do you secure a Kubernetes cluster?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** governs *who can do what* on the API. Permissions are granted to **subjects** (users, groups, **ServiceAccounts**) by **binding** them to **Roles** that list allowed verbs on resources. RBAC is one layer of a broader cluster-hardening strategy.

## The RBAC model

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Role + RoleBinding example

```yaml
# A Role: read-only access to Pods in the "app" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind that Role to a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: identity for Pods

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # opt out if no API calls are needed
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # run Pods under this identity
```

## Defense in depth — beyond RBAC

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # what can the current user do?
```

## Why it matters

Securing a cluster is a senior responsibility, and RBAC with ServiceAccounts is its foundation, so understanding both is essential security knowledge. The RBAC model is elegant and worth internalizing: permissions are **purely additive with no deny**, granted by **binding subjects** (users, groups, and especially **ServiceAccounts**) to **Roles** (namespaced) or **ClusterRoles** (cluster-wide) that enumerate allowed **verbs on resources** — which means good security comes from granting only what each workload needs (**least privilege**) rather than relying on denials. Understanding that a **ServiceAccount is the identity a Pod uses to call the API** — that every Pod gets a token, that the `default` SA is a common over-privilege trap, and that you should give each workload its own least-privilege SA (and disable token automounting when no API access is needed) — is directly practical and a frequent source of real-world misconfiguration. Crucially, a senior engineer knows RBAC is only one layer of **defense in depth**: default-deny **NetworkPolicies**, hardened **securityContext** settings (non-root, read-only root filesystem, dropped capabilities, seccomp), **Pod Security Admission**, **encryption at rest** and external managers for Secrets, image scanning and signing, admission controllers (OPA/Gatekeeper, Kyverno), and locked-down etcd/API access all combine to protect a cluster. Because a Kubernetes cluster is a high-value target where a single over-permissioned ServiceAccount or open NetworkPolicy can lead to full compromise, mastering RBAC and the broader hardening toolkit is fundamental to operating clusters safely in production.

The RBAC model

Role + RoleBinding example

ServiceAccounts: identity for Pods

Defense in depth — beyond RBAC

Why it matters

Related questions