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. 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 is open to the internet, and a hardened cluster does not help if the cloud account credentials leak.

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. On the exam, the 4Cs appear in two ways: naming the four layers, and classifying a given control into its layer. Practice the second form, because most of the controls in this lesson are Cluster-layer or Container-layer answers.

Every request to the Kubernetes API is first authenticated (who are you?) and then authorized (are you allowed to do this?). The standard authorization mechanism is Role-Based Access Control (RBAC). RBAC has four objects in a clean two-by-two: a Role grants permissions within one namespace, a ClusterRole grants them cluster-wide, and a RoleBinding or ClusterRoleBinding attaches those permissions to subjects: users, groups, or ServiceAccounts. Permissions are expressed as verbs on resources, such as get and list on pods.

RBAC is purely additive: rules only ever allow, and there is no deny rule. Anything not granted is refused. That design 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, which is 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, and every Pod runs as one, with a token that can be mounted into the container. The security lens: most applications never call the Kubernetes API, so they need no API permissions at all, and mounting the token can be disabled with automountServiceAccountToken: false. Workloads that do need API access should get a dedicated ServiceAccount bound to a minimal Role, so a compromised container yields as little power as possible.

Kubernetes offers two objects for injecting configuration into Pods. A ConfigMap holds non-sensitive settings; a Secret holds sensitive data such as passwords, API tokens, and TLS keys. Both can be delivered to containers as environment variables or as files in a mounted volume. The exam's favorite fact sits in the storage column below.

base64 is an encoding, not encryption. Anyone who can read the Secret object can decode its values with one command, and by default Secrets sit in etcd unencrypted. Real protection comes from three practices: enable encryption at rest by configuring an EncryptionConfiguration for the kube-apiserver so Secrets are encrypted before they reach etcd; restrict who can get and list Secrets with RBAC; and limit which ServiceAccounts and Pods mount each Secret. Managed clusters often integrate a cloud key management service for the same purpose, and external secret managers such as HashiCorp Vault are common at recognition depth.

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

Some Pod specifications are inherently dangerous: privileged containers, host network access, or host path mounts can hand a workload control of its node. Kubernetes needed a built-in way to refuse such Pods. The original mechanism, PodSecurityPolicy (PSP), proved hard to use and was removed in Kubernetes 1.25. Its replacement is Pod Security Admission (PSA), an admission controller built into the API server that checks Pods against the three Pod Security Standards:

PSA is applied per namespace with labels, and each level can be combined with one of three modes: enforce rejects violating Pods, audit records violations in the audit log, and warn returns a warning to the client but admits the Pod. For example, labeling a namespace with pod-security.kubernetes.io/enforce: restricted makes the API server reject any Pod in that namespace that does not meet the Restricted standard. For the exam, memorize the three levels in order of increasing strictness, the three modes, the namespace-label mechanism, and the PSP-removed-in-1.25 fact.

Pod Security Admission decides whether a Pod is admitted; securityContext is where you declare the hardened settings themselves. 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 exam fields are the ones the Restricted standard expects:

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

• runAsNonRoot: refuses to start the container if its process would run as root, shrinking the blast radius of a compromise.
• allowPrivilegeEscalation: false: prevents the process from gaining more privileges than its parent, for example via setuid binaries.
• readOnlyRootFilesystem: makes the container's root filesystem immutable, so an intruder cannot write tools or tamper with binaries; writable scratch space comes from explicit volumes.
• capabilities: drop ALL: removes Linux kernel capabilities, granting back only the specific ones a workload truly needs.
• seccompProfile RuntimeDefault: filters which system calls the container may make, using the runtime's default profile.

Scenario: an attacker exploits a vulnerability in a web application container. With this securityContext, the process is not root, cannot escalate, cannot write to its own filesystem, holds no dangerous kernel capabilities, and is restricted in the system calls it can attempt. Each field independently frustrates a step of the attack: defense in depth at the Container layer of the 4Cs.

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. NetworkPolicy is the control that removes this 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 for the exam: NetworkPolicies are enforced by the CNI plugin, so a plugin without policy support (such as plain Flannel) silently ignores them, and this control belongs to the Cluster layer of the 4Cs.

Admission control is the API server's checkpoint between authorization and persistence: after a request is authenticated and authorized, admission controllers can still mutate it or reject it based on policy. Pod Security Admission is one built-in example. Clusters can also register webhooks that call out to external policy engines, and tools like OPA Gatekeeper and Kyverno use this to enforce custom rules, such as refusing images from unknown registries or requiring resource limits. At KCNA depth, know the concept: 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. The recognition-level practices:

• Image scanning: tools such as Trivy inspect images for known vulnerabilities (CVEs) in OS packages and application dependencies, ideally in the CI pipeline before push and continuously in the registry.
• Image signing: projects such as Sigstore's cosign attach cryptographic signatures to images, so a cluster can verify an image really came from your pipeline and was not tampered with; verification is typically enforced by an admission webhook.
• SBOM (Software Bill of Materials): a machine-readable inventory of every component inside an artifact, which lets you answer, when the next big vulnerability lands, exactly which images contain the affected library.

Round this out with minimal base images, which carry fewer packages and therefore fewer vulnerabilities, and pulling only from trusted registries. Together these practices ensure that what runs in the cluster is known, verified, and as small as possible.