Kubernetes Security: The 4Cs, RBAC, Secrets, and Pod Security Admission

The 4Cs of Cloud Native Security model a system as four nested layers: Cloud, Cluster, Container, Code, from outermost to innermost. Your code runs inside a container, the container runs inside a cluster, and the cluster runs on a cloud or datacenter. Each layer can only be as secure as the layers outside it allow: flawless application code does not help if the cluster's API server accepts anonymous requests, and a hardened cluster does not help if the cloud account credentials leak.

Classify a control by asking what it configures: the infrastructure underneath Kubernetes (Cloud), Kubernetes objects and API server settings (Cluster), the image or the container's runtime settings (Container), or the application's own source and dependencies (Code).

The point of the model is defense in depth: no single control is trusted to hold, so each layer adds its own protections and an attacker must defeat several independent barriers. A weakness in an outer layer undermines the inner ones; it does not leave them unaffected. The 4Cs appear in two ways: naming the layers in order, and classifying a given control into its layer. Practice the second form, because most controls in this lesson are Cluster-layer or Container-layer.

RBAC is how Kubernetes decides whether an authenticated subject may perform an action: every API request is first authenticated (who are you?), then authorized (are you allowed to do this?). Role-Based Access Control (RBAC) has four objects in a two-by-two: a Role defines permissions within one namespace, a ClusterRole defines them without a namespace, and a RoleBinding or ClusterRoleBinding attaches those permissions to subjects: users, groups, or ServiceAccounts. Permissions are verbs on resources, such as get and list on pods.

The binding, not the role, decides where permissions apply:

A RoleBinding cannot reference a Role from another namespace. Referencing a ClusterRole from RoleBindings is the reuse pattern: define a common set of rules once as a ClusterRole, then create a RoleBinding in each namespace where a team needs them. The team gets those rules only in those namespaces, not cluster-wide, and the rules are maintained in one place.

RBAC is purely additive: rules only ever allow, and there is no deny rule. Anything not granted is refused. That makes least privilege the operating principle: grant the narrowest verbs, on the narrowest resources, in the narrowest scope that lets the subject do its job. A deployment pipeline that only updates Deployments in the shop namespace should hold a Role in that namespace, not a ClusterRoleBinding to cluster-admin, the canonical example of excessive privilege.

Humans are not the only subjects. A ServiceAccount is the identity a Pod uses when its processes call the Kubernetes API. Every namespace has a default ServiceAccount, every Pod runs as one, and by default a token for it is mounted into the containers. Most applications never call the Kubernetes API, so they need no API permissions and no token: setting automountServiceAccountToken: false (on the Pod or the ServiceAccount) means a compromised container finds no API credentials at all. Workloads that do need API access should get a dedicated ServiceAccount bound to a minimal Role.

A Secret holds sensitive data such as passwords, API tokens, and TLS keys, while a ConfigMap holds non-sensitive settings; both can be delivered to containers as environment variables or as files in a mounted volume. The difference is protection, not delivery.

base64 is an encoding, not encryption. It only lets binary values travel in the API object; it is neither the protection nor the form in which Secrets are stored. Anyone who can read the Secret object can decode its values with one command, and with upstream API server defaults Secrets sit in etcd unencrypted. Many managed Kubernetes services turn on etcd or envelope encryption for you, so check your provider before assuming either way.

Two controls protect Secrets against two different threats:

• RBAC restricts who can get, list, and watch Secrets through the API. It does nothing against someone who reads etcd directly, such as from a stolen etcd backup or disk.
• Encryption at rest addresses that second threat. You give the kube-apiserver an EncryptionConfiguration that lists a real provider (aescbc, aesgcm, secretbox, or kms v2, which uses an external key management service for envelope encryption; upstream documentation recommends kms v2 or secretbox over aescbc) ahead of identity, the no-encryption provider. The first provider encrypts new writes; Secrets that already exist stay unencrypted until they are rewritten, for example by replacing every Secret.

Also limit which ServiceAccounts and Pods mount each Secret; external secret managers such as HashiCorp Vault are common at recognition depth. Do not confuse protection with immutable Secrets: immutable: true blocks updates to a Secret (preventing accidental changes and reducing API server watch load) but does not encrypt anything.

Delivery method matters too. Values mounted as volume files are updated in the container when the Secret changes (unless mounted with subPath), while environment variables are fixed at container start and are easier to leak through logs and diagnostic dumps, so volume mounts are generally preferred for sensitive material.

Pod Security Admission (PSA) is the admission controller built into the API server that checks Pods against the three Pod Security Standards. It exists because some Pod specifications are inherently dangerous: privileged containers, host network access, or hostPath mounts can hand a workload control of its node. Its predecessor, PodSecurityPolicy (PSP), proved hard to use. The timeline is a common source of distractors:

PSA is applied per namespace with pod-security.kubernetes.io/<mode>: <level> labels, in three modes that differ in what happens to a violating Pod:

In short, audit is the mode for building a record of violations for later review without affecting anyone, while warn is the mode for giving feedback to the person submitting the workload; neither blocks admission. Each mode takes its own level, so one namespace can combine them, for example enforce: baseline with warn: restricted and audit: restricted: Pods must meet Baseline today, while developers see which ones would fail Restricted. That is the usual migration pattern toward a stricter level. Enforce checks Pods themselves; warn and audit also flag workload objects such as Deployments whose Pod template would violate.

securityContext is where you declare a container's hardened settings; Pod Security Admission only decides whether a Pod with those settings is admitted. It appears at two levels of a Pod spec: Pod-level settings apply to all containers, and container-level settings override them for one container. The recurring fields are the ones the Restricted standard expects:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

• runAsNonRoot: true: a check, not a choice. When the container starts, the kubelet verifies that it will not run as UID 0; if the image's user is root (or a non-numeric user it cannot verify) and no non-root runAsUser is set, the container fails to start with CreateContainerConfigError. It never picks a user for you.
• runAsUser: chooses the UID the process runs as, overriding the image's user.
• allowPrivilegeEscalation: false: sets the Linux no_new_privs flag, so the running process cannot later gain more privileges than its parent, for example through setuid binaries. It is always effectively true for privileged containers or those with CAP_SYS_ADMIN.
• readOnlyRootFilesystem: makes the container's root filesystem immutable, so an intruder cannot write tools or tamper with binaries; paths the app must write to, such as a cache or temp directory, get an explicit writable volume like emptyDir.
• capabilities: drop ALL: removes Linux kernel capabilities, granting back only the specific ones a workload truly needs; privileged: true is the opposite, giving the container almost full access to the host.
• seccompProfile RuntimeDefault: filters which system calls the container may make, using the runtime's default profile.

The two complement each other: a container can start as a non-root user and still escalate through a setuid binary unless escalation is also blocked. With the full set above, a compromised web container is not root, cannot escalate, cannot write to its own filesystem, holds no dangerous kernel capabilities, and is restricted in its system calls: defense in depth at the Container layer of the 4Cs.

NetworkPolicy is the security control that limits which Pods can talk to which. Kubernetes networking is default-allow: with no policies in place, every Pod can open connections to every other Pod in the cluster. From a security standpoint that means one compromised workload can probe and attack everything else, a pattern called lateral movement. Policies are how you remove that freedom.

A NetworkPolicy is a namespaced object that selects Pods with a podSelector and lists allowed ingress sources and egress destinations by Pod labels, namespace labels, or IP ranges. The pivotal behavior: a Pod selected by no policy accepts all traffic, but once any policy selects it, traffic in the covered directions is denied unless explicitly allowed. Policies are additive allow-lists; like RBAC, there are no deny rules to write. A policy with an empty podSelector selects every Pod in its namespace, which is how teams apply a default-deny baseline and then add narrow allowances per workload.

Scenario: a payment namespace runs a frontend, an api, and a database. Under default-allow, a compromised frontend can connect straight to the database and attempt to dump it. After a default-deny policy plus rules allowing only frontend-to-api and api-to-database traffic, that path no longer exists: the frontend has no allowed route to the database, so the intrusion is contained at the first hop. Two supporting facts complete the picture. NetworkPolicies are enforced only when the cluster's CNI plugin supports them: the API server accepts the objects either way, but a plugin without policy support (such as plain Flannel) silently ignores them, so confirm support before relying on this control. And NetworkPolicy belongs to the Cluster layer of the 4Cs. Note what it does not do: RBAC limits API actions and Pod Security Admission limits Pod specs, but neither stops a compromised Pod opening network connections; only NetworkPolicy limits that lateral movement.

Admission control is the API server's checkpoint between authorization and persistence: after a request is authenticated and authorized, admission controllers can still change it or reject it based on policy before it is stored in etcd. The order matters:

1. Authentication, then authorization (RBAC). A request RBAC denies is rejected here and never reaches any admission controller or webhook.
2. Mutating admission, including mutating webhooks, which can change the object, for example by injecting defaults or a sidecar.
3. Validating admission, including validating webhooks and Pod Security Admission, which accept or reject the object as mutated. Validating controllers see the final object, so they can check what mutation produced.
4. Persistence to etcd.

Clusters register webhooks to call external policy engines: OPA Gatekeeper and Kyverno use this to enforce custom rules, such as refusing images from unknown registries or requiring resource limits. Admission control is where cluster-wide policy is applied to objects before they are stored.

The supply chain is everything that happens before an image reaches the cluster, spanning the Code and Container layers of the 4Cs:

• Image scanning: tools such as Trivy inspect images for known vulnerabilities (CVEs) in OS packages and application dependencies, ideally in CI before push and continuously in the registry.
• Image signing: Sigstore's cosign attaches a cryptographic signature to an image, proving which pipeline or identity produced it and that it was not altered.
• Signature verification at admission: signing only helps if the cluster checks it. Kyverno image verification rules or the Sigstore policy-controller run as admission webhooks and refuse Pods whose images lack a valid signature from your CI, so an image someone built and pushed by hand cannot run.
• SBOM (Software Bill of Materials): a machine-readable inventory of every component inside an artifact, so when the next major vulnerability lands you can tell which images contain the affected library.

Two common controls do not establish provenance. An imagePullSecret only supplies credentials for pulling from a private registry; it does not restrict which registry or image a Pod references. Pinning an image by digest guarantees you get exactly those bytes every time (immutability), but says nothing about who built them. Round this out with minimal base images, which carry fewer packages and therefore fewer vulnerabilities, and trusted registries. Together these practices ensure that what runs in the cluster is known, verified, and as small as possible.