Lesson 12 · Scaling, scheduling & reliability
Namespaces, RBAC & ServiceAccounts
Partitioning the cluster and controlling who — and which Pod — may do what.
Your win: explain namespaces (and how they map to the env×org model), RBAC (Role + RoleBinding), and ServiceAccounts as Pod identity — including how this repo's Pods reach Google APIs with no long-lived keys.
Namespaces — virtual clusters within a cluster
A namespace partitions a cluster: it scopes object names, and is the unit
for quotas and access control.1 Names are unique
within a namespace, not across — which is why cluster DNS (Lesson 5) includes the
namespace: bob.local-manabie-backend.svc.cluster.local.
(env, org) cell is a namespace:
{{.ENV}}-{{.ORG}}-backend, set in Skaffold
(deployments/helm/backend/bob/skaffold.yaml:10) — e.g.
local-manabie-backend, prod-tokyo-backend,
stag-jprep-backend. So the whole multi-tenant, multi-environment structure is
expressed as Kubernetes namespaces. One customer's staging can't accidentally reference
another's prod — different namespaces, isolated names and policies. The
backend/common chart even adds per-namespace
NetworkPolicies and a LimitRange.
RBAC — who may do what
Role-Based Access Control answers "can this subject perform this verb on this resource?" Two halves:2
- A Role (namespaced) or ClusterRole (cluster-wide) lists
permissions: verbs (
get,list,create…) on resources (pods, services…). - A RoleBinding / ClusterRoleBinding grants that Role to a subject: a user, group, or ServiceAccount.
RBAC secures the single choke-point from Lesson 2 — everything goes through the api-server, so controlling verbs there controls the cluster.
ServiceAccounts — identity for Pods, not people
A ServiceAccount (SA) is the identity a Pod runs as, used to authenticate to the api-server (and, via cloud integration, to external services).3 Every Pod has one.
iam.gke.io/gcp-service-account: <name>@<project>.iam.gserviceaccount.com
(:61). That annotation ties the Kubernetes SA to a Google service account, so the Pod
authenticates to Google APIs (Cloud SQL, Pub/Sub, KMS — the SOPS decryption
from Lesson 6!) with no long-lived key files. This is the mechanism behind Lesson
6's "decrypts in-process" — the Pod's SA identity is its credential. The details
are Course 7 (IaC).
ClusterRoleBinding to cluster-admin — but that's a
local test tool, not a production grant. Least privilege: don't hand out
Roles nobody needs.
Kubernetes docs — Namespaces, RBAC & ServiceAccounts
Namespace scoping, the Role/RoleBinding model, and how ServiceAccounts give Pods an identity.
→ kubernetes.io — Namespaces
→ kubernetes.io — RBAC ·
ServiceAccounts
Check yourself (from memory)
Q1. In this repo, a Kubernetes namespace corresponds to…
local-manabie-backend, set in Skaffold.
Q2. RBAC grants permissions by pairing a Role with a…
Q3. Workload Identity lets a Pod reach Google APIs by…
{ENV}-{ORG}-backend (bob/skaffold.yaml:10), e.g.
local-manabie-backend; common chart adds NetworkPolicy + LimitRange. RBAC =
ROLE/ClusterRole (verbs on resources) + ROLEBINDING/ClusterRoleBinding (grant to a subject:
user/group/SA). SERVICEACCOUNT = a Pod's identity to the api-server. Repo:
_serviceaccount.tpl:25 annotates each SA for GCP WORKLOAD IDENTITY
(iam.gke.io/gcp-service-account, :61) → Pods reach Google APIs (Cloud SQL, KMS
for SOPS) with NO long-lived keys. RBAC minimal (only gandalf's local cluster-admin).libs/util library chart, aligned to the CKA/CKAD
syllabus, and wired to your other courses (containers → pods, Kafka lag → KEDA, SOPS → KMS
via Workload Identity). Course 3 (Helm) is the natural sequel — it explains
the templating engine that generated every object you just learned.