Cluster security

Every security question about a cluster collapses into one of two doors. The first faces outward at the humans and pipelines that run kubectl against the API server — who they are, and what they are permitted to do once they are in. The second faces inward at the pods, which almost always need to reach back into Azure for a Key Vault secret, a storage account, a database — and the question there is how a pod proves who it is without you burying a password in a manifest. Keep the two doors separate in your head and the rest of this part is bookkeeping.

You have seen both doors before, one class each. Class Eight was role-based access control — the discipline of granting the smallest set of permissions a job needs, no more — and it applies here almost unchanged, only now the resource being guarded is the cluster and the verbs are things like "list pods" and "create deployments." Class Nine was managed identity — an Azure resource proving its identity to another Azure service with no stored secret. This part is those two ideas walked through the cluster's front and back doors, plus the machinery that hardens what runs inside once the doors are shut.

Split the front door into its two halves. Authentication — proving who is at the keyboard — is handed to Microsoft Entra ID. With Entra integration turned on, nobody authenticates to the cluster with a static certificate or a shared local admin account; they sign in as their Entra identity, which means the same account, the same conditional-access rules, and the same offboarding that governs the rest of your Azure estate also governs the cluster. When someone leaves the company and their Entra account is disabled, their cluster access dies in the same breath — you do not have to remember a second place to revoke it.

The second half — authorization, deciding what that proven identity may do — you can run one of two ways. Azure RBAC for Kubernetes lets you grant Kubernetes permissions using Azure role assignments, so cluster access is managed in the same place, and audited in the same log, as every other Azure permission. The alternative is native Kubernetes RBAC, where Roles and RoleBindings live inside the cluster as objects; you still authenticate with Entra, but you manage the grants in-cluster. Azure RBAC for Kubernetes is the tidier default for an Azure-native shop because it keeps one control plane for permissions; native RBAC wins when you want portable, in-cluster rules that travel with the manifests.

Prove who with Entra. Decide what with RBAC.

Either way, the rule from Class Eight holds without amendment: grant a namespace-scoped role, not cluster-admin, and grant it to a group rather than a person so that access follows the org chart instead of a wiki page nobody updates. A read-only role on one namespace is the correct starting point for almost everyone; the engineer who genuinely needs to deploy gets exactly that verb on exactly that namespace, and the blast radius of a stolen credential is bounded before it is ever stolen.

Now the inward door. A pod needs to read a secret from Key Vault. The lazy answer — the one that fails an audit — is to paste the secret, or a service-principal password, into a Kubernetes Secret and mount it. You saw in §27b that a Kubernetes Secret is only base64, not encrypted at rest by default, so that password is one kubectl get secret -o yaml away from anyone with read access to the namespace. The right answer is to store no credential in the cluster at all.

Microsoft Entra Workload ID is how. The cluster is registered as an OIDC issuer, and a Kubernetes service account is federated to a Microsoft Entra identity. When the pod needs an Azure token, its service-account token — a short-lived, cluster-signed JWT — is exchanged with Microsoft Entra ID for a real Azure access token, because Entra has been told to trust tokens from this specific issuer and subject. The pod ends up holding a normal Azure token it can use against Key Vault or any other service, and at no point did a long-lived secret sit in a manifest. This is the Class Nine managed-identity pattern, now reaching inside the cluster: identity proven by federation, not by a shared password.

Say the deprecation plainly, because the old tutorials will mislead you. Workload ID replaces the earlier pod-managed-identity add-on (the aad-pod-identity project), which is deprecated and being retired. Do not build anything new on pod-managed-identity; if you inherit it, the migration target is Workload ID. The federation model is simpler, has fewer moving parts in the cluster, and does not depend on intercepting the node's instance-metadata endpoint the way the old add-on did.

Doors settle who may act; the next question is whether what is already running is trustworthy. Two surfaces matter: the images you pull, and the privileges the pods run with. For images, Microsoft Defender for Containers scans them where they sit in the registry — flagging known vulnerabilities in a base image or a pulled-in library before it ever reaches a node — and adds runtime threat detection that watches for the behaviour of a compromised container, the shell that should not have spawned, the connection that should not have opened. It is the difference between finding a bad image on a Tuesday scan and finding it in an incident post-mortem.

For privileges, the current tool is Pod Security Admission — a built-in Kubernetes admission controller you configure per namespace with a label, choosing a profile and a mode. The profiles are baseline (block the obviously dangerous — host networking, most privileged containers) and restricted (a hardened, least-privilege posture that also drops root and forbids privilege escalation). The modes are enforce (reject a non-compliant pod), audit (allow it but log the violation), and warn (allow it but warn the user applying it). The usual path is to label a namespace audit and warn at restricted first, read what breaks, then switch to enforce once nothing legitimate trips it.

One correction you must carry, because half the material online predates it: PodSecurityPolicy (PSP) was removed in Kubernetes 1.25. It no longer exists. Do not learn it, do not reach for it, do not copy a manifest that references it — the replacement is Pod Security Admission for the namespace-level baseline, and Azure Policy for AKS when you want those guardrails defined centrally, audited, and applied across every cluster in the subscription from one place rather than remembered namespace by namespace.

Notice the single principle threading every row of that table: grant the least a thing needs, and prove identity without shipping a secret. The read-only namespace role, the restricted Pod Security profile, the federated token that replaces a password — each is the same instinct applied at a different layer. Security on a cluster is not one feature you switch on; it is a posture you hold at every door and inside every room, and the reason it reads as a discipline rather than a checklist is that the attacker only needs the one door you left generous.

The engineer's version of this is uncomfortable but worth saying: most breaches are not exotic. They are a cluster-admin credential handed out because narrowing the role was five minutes of work nobody did, or a service-principal password committed to a repo because federation looked like more setup on a Friday. The senior move is to make the secure path the low-effort path — a group with a scoped role, a Workload ID federation done once — so that the lazy choice and the safe choice are the same choice. That is the half of the model no provider will hold for you, and it is precisely the half you are paid to.