Kubernetes Security Fundamentals for the KCSA Exam: Authentication, RBAC, Pod Security Standards, Secrets, Network Policy & Audit Logging

Introduction

Kubernetes Security Fundamentals is the joint-largest domain on the KCSA exam, worth 22% of your score — tied with Cluster Component Security. If Cluster Component Security is about hardening the machinery of a cluster, Security Fundamentals is about the controls you apply to workloads and access every single day: who can authenticate, what they’re allowed to do, how Pods are constrained, how Secrets are protected, and how traffic is segmented.

The KCSA is a knowledge-based, multiple-choice exam, so it doesn’t ask you to author a flawless RBAC policy from scratch. It asks you to reason: A ServiceAccount can list Secrets cluster-wide — which object granted that, and how would you scope it down? A namespace enforces the Restricted Pod Security Standard — will a Pod requesting privileged: true be admitted? Getting those right means understanding each control’s job and its default behavior.

This guide walks the Security Fundamentals domain the way the exam tests it — control by control, with the manifests and defaults that matter. Everything here is verifiable against the official Kubernetes documentation. If you’re still mapping the whole blueprint, start with the KCSA exam guide for 2026 and the KCSA study plan. The 4Cs of Cloud Native Security, the Kubernetes threat model, and Cluster Component Security cover the neighboring domains.

The Request Journey: Authn → Authz → Admission

Every request to the Kubernetes API server passes through three gates, in order. Losing track of this sequence is the single most common source of wrong answers on this domain.

Stage	Question it answers	Mechanisms
Authentication	Who are you?	Client certs, bearer tokens, ServiceAccount tokens, OIDC, authenticating proxy
Authorization	Are you allowed to do this?	RBAC, Node, Webhook, ABAC
Admission control	Should this specific object be allowed (and possibly changed)?	PodSecurity, validating/mutating webhooks, ResourceQuota

A request must clear all three before it takes effect. Authentication only establishes identity — it grants nothing. Authorization decides capability. Admission has the final say on the object’s contents. Keep these separate in your head and most trick questions on this domain fall apart.

Authentication: Kubernetes Has No User Objects

The most tested authentication fact on the KCSA is counterintuitive: Kubernetes does not have a User resource. There is no kubectl create user. Human identities come from outside the cluster and are proven to the API server one of a few ways:

X.509 client certificates — the CN (Common Name) becomes the username; the O (Organization) fields become the user’s groups. Signed by the cluster CA.
Bearer tokens — including OIDC tokens from an external identity provider (the production pattern for humans) and static token files (discouraged).
ServiceAccount tokens — the identity used by in-cluster workloads. These are real Kubernetes objects (ServiceAccount), unlike human users.

# A ServiceAccount is a first-class object — this is the identity Pods use
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payments-reader
  namespace: payments

Key exam points:

Anonymous requests map to the user system:anonymous in the group system:unauthenticated. If --anonymous-auth=false is set on the API server, they’re rejected outright.
ServiceAccounts vs. users: ServiceAccounts are namespaced objects managed by Kubernetes; users are managed outside it. The exam loves distractors that claim you can “create a user with kubectl.”
Modern ServiceAccount tokens are short-lived and audience-bound (projected via the TokenRequest API), not the legacy long-lived Secret-backed tokens.

Authorization: RBAC Is the Whole Game

Once you’re authenticated, RBAC (Role-Based Access Control) decides what you can do. RBAC is built from exactly four object types, and the exam expects you to know which is namespaced and which is cluster-scoped:

Object	Scope	Grants
Role	Namespaced	Permissions within one namespace
ClusterRole	Cluster-wide	Permissions across all namespaces or on cluster-scoped resources
RoleBinding	Namespaced	Binds a Role or ClusterRole to subjects, effective in one namespace
ClusterRoleBinding	Cluster-wide	Binds a ClusterRole to subjects across the whole cluster

A Role lists verbs (get, list, watch, create, update, delete) on resources (pods, secrets, deployments):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: secret-reader
rules:
  - apiGroups: [""]           # "" = the core API group
    resources: ["secrets"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: payments
subjects:
  - kind: ServiceAccount
    name: payments-reader
    namespace: payments
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

The mental model the exam rewards:

RBAC is purely additive and default-deny. There is no Deny rule. If no binding grants an action, it’s denied. You never “remove” access with RBAC — you simply don’t grant it.
A RoleBinding can reference a ClusterRole. This is a common, useful pattern: define a reusable ClusterRole once, then bind it into individual namespaces. The permissions apply only in the RoleBinding’s namespace.
A ClusterRoleBinding + ClusterRole grants access everywhere — the most dangerous combination to get wrong. Binding a broad ClusterRole (like cluster-admin) to a workload’s ServiceAccount is a classic privilege-escalation finding.
Least privilege: scope every ServiceAccount to only the verbs and resources it needs, in only the namespace it runs in.

For the hands-on, CKS-level version of RBAC design, see the CKA RBAC hands-on guide and CKS cluster setup and hardening. The KCSA tests the concepts; those exams test the kubectl.

Pod Security Standards and Pod Security Admission

You can lock down who talks to the API server and still run wildly insecure Pods. Pod Security Standards (PSS) define three cumulative policy levels, and Pod Security Admission (PSA) — the built-in admission controller that replaced the deprecated PodSecurityPolicy — enforces them at the namespace level.

Standard	What it allows	Use for
Privileged	Unrestricted — anything goes	Trusted, infrastructure-level workloads
Baseline	Blocks known privilege escalations (no `privileged`, no host namespaces, limited capabilities)	Most non-critical applications
Restricted	Heavily hardened — enforces `runAsNonRoot`, drops all capabilities, requires seccomp	Security-sensitive workloads

PSA is configured with namespace labels, and it runs in three independent modes:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted   # reject violating Pods
    pod-security.kubernetes.io/audit: restricted      # log violations to the audit log
    pod-security.kubernetes.io/warn: restricted       # warn the user on kubectl apply

Exam-critical distinctions:

enforce blocks; audit and warn do not. A Pod that violates the standard is only rejected under enforce. Under audit it’s still created (and logged); under warn it’s created (with a user-facing warning). The exam frequently asks “the Pod was created despite violating the policy — why?” The answer is usually “the namespace was in audit/warn mode, not enforce.”
The three modes are independent and can point at different levels — a common real-world pattern is enforce: baseline with warn: restricted to prepare for a future tightening.
PSA is namespace-scoped, so isolation between teams often starts with putting each in its own namespace at the appropriate standard.
PodSecurityPolicy (PSP) is removed. If an answer choice recommends PSP, it’s wrong for any current cluster.

The Pod-level securityContext is what actually satisfies the Restricted standard:

spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myorg/app:1.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Secrets: Base64 Is Not Encryption

Secrets get their own attention on this domain because of one persistent misconception the exam probes relentlessly:

A Kubernetes Secret is only base64-encoded, not encrypted. Anyone who can read the Secret object — or read etcd — can trivially decode it.

Base64 is reversible with a single command, so the protections that actually matter are:

Control	What it does
Encryption at rest	Configure an `EncryptionConfiguration` (ideally KMS-backed) so Secrets are encrypted before being written to etcd
RBAC on Secrets	Restrict `get`/`list`/`watch` on `secrets` to the minimum ServiceAccounts — reading Secrets should be a rare, scoped privilege
Least mounting	Only mount a Secret into Pods that need it; prefer projected, short-lived tokens
External secret stores	Integrate an external vault via the Secrets Store CSI driver so sensitive material never lives in etcd

A subtle but tested point: anyone with list secrets permission in a namespace can read every Secret value in that namespace. That’s why broad Secret-read grants are treated as near-admin access. Segmenting Secrets across namespaces and scoping RBAC tightly is the mitigation.

Isolation and Segmentation

The KCSA groups several controls under “isolation and segmentation” — the idea that a compromise in one place shouldn’t spread. The primitives:

Namespaces — the fundamental soft boundary for RBAC, ResourceQuotas, and Network Policies. Note the word soft: namespaces are not a hard security boundary by themselves. A Pod that breaks out to the node ignores namespaces entirely.
Network Policies — segment traffic between Pods (covered next).
ResourceQuota and LimitRange — prevent one namespace from exhausting cluster resources, which is a denial-of-service control.
Node isolation — taints, tolerations, and nodeSelector/affinity to keep sensitive workloads on dedicated nodes; runtime sandboxes (gVisor, Kata) for hard multi-tenancy.

The exam’s framing: namespaces + RBAC + Network Policies together give you defense in depth, but no single one is a complete boundary.

Network Policies: Default-Allow Until You Say Otherwise

By default, every Pod in a Kubernetes cluster can talk to every other Pod — the network is flat and open. A NetworkPolicy changes that, but only for Pods it selects, and only if your CNI plugin supports it (Calico, Cilium, and others do; some basic CNIs do not — a fact the exam checks).

The most important pattern is default-deny, which flips a namespace from open to closed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}          # selects every Pod in the namespace
  policyTypes:
    - Ingress
    - Egress

With podSelector: {} and no ingress/egress rules, all traffic is denied. You then add explicit allow policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

What the exam tests:

Network Policies are additive and default-deny once a Pod is selected. A Pod not selected by any policy remains fully open; a Pod selected by any policy is denied everything except what its policies allow.
They select by label, not IP. podSelector and namespaceSelector are the tools; hardcoded IPs are an anti-pattern in a world of ephemeral Pods.
Enforcement depends on the CNI. Writing a NetworkPolicy against a CNI that doesn’t implement it silently does nothing — a favorite “why didn’t this work?” scenario.

Audit Logging: The Record of What Happened

Audit logging is where the API server records who did what, when, and to which object — indispensable for incident response and a fundamental control the KCSA expects you to understand conceptually. Auditing is configured with an audit policy that sets a level per rule:

Level	What it records
None	Nothing (used to exclude noisy requests)
Metadata	Request metadata — user, verb, resource, timestamp — but no bodies
Request	Metadata plus the request body
RequestResponse	Metadata plus request and response bodies

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log Secret access at Metadata only — never log secret values in bodies
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  # Log everything else at Request level
  - level: Request

Exam points that matter:

Never log Secret bodies. Using RequestResponse on secrets would write plaintext values into the audit log. Best practice — and a common exam answer — is Metadata for Secrets.
Audit events pass through stages (RequestReceived, ResponseComplete, etc.); the policy decides what’s captured at each.
The audit log is an API-server responsibility (--audit-policy-file, --audit-log-path), tying this domain back to Cluster Component Security.

Common Mistakes on This Domain

Mistake	Reality
Thinking authentication grants access	Authn only proves identity; RBAC (authorization) grants capability
Believing you can `kubectl create user`	Kubernetes has no User object; humans authenticate from outside
Assuming RBAC has deny rules	RBAC is additive and default-deny; you don’t “remove” access, you don’t grant it
Expecting `audit`/`warn` PSA modes to block Pods	Only `enforce` rejects violating Pods
Treating Secrets as encrypted	They’re base64-encoded; enable encryption at rest and scope RBAC
Assuming Pods are isolated by default	The Pod network is flat; you need Network Policies to segment it
Writing a NetworkPolicy on a CNI that ignores it	Enforcement requires a policy-capable CNI (Calico, Cilium, etc.)

Conclusion

Security Fundamentals rewards a clean model of access and constraint. If you can trace a request through authentication → authorization → admission, explain why RBAC is default-deny and additive, recall that only PSA’s enforce mode blocks Pods, remember that Secrets are merely base64-encoded, and know that Network Policies flip a namespace from open to closed only for the Pods they select — you’ll convert most of this 22% slice into reliable points.

The gap between reading these controls and recognizing them under exam pressure is closed the same way every time: by drilling scenario questions until the right control is the obvious answer.

Practice Until Every Control Is Automatic

Understanding RBAC, Pod Security Standards, and Network Policies on paper is the foundation; answering timed, scenario-based questions is what turns that foundation into exam readiness. Concepts tell you why a control exists; practice questions surface the edge cases you didn’t know you were missing.

Sailor.sh’s KCSA mock exam bundle mirrors the real exam’s domain weights, so Security Fundamentals gets the emphasis its 22% deserves — every question comes with an explanation of why the answer is correct, not just which option to choose. Benchmark yourself first with the free KCSA practice questions, then close the gaps with full mock exams and the KCSA study plan. Still deciding whether the cert fits your path? Is KCSA worth it? and KCSA vs. CKS lay out the case.

Frequently Asked Questions

Why is Kubernetes Security Fundamentals worth 22% of the KCSA?

It’s tied for the largest domain because these are the controls practitioners apply every day — authentication, RBAC, Pod Security Standards, Secrets, and Network Policies. Nearly every real-world hardening effort and most exam scenarios draw on them, so the blueprint weights them heavily.

Can you create a user in Kubernetes with kubectl?

No. Kubernetes has no User object and no command to create one. Human users are authenticated from outside the cluster — via X.509 client certificates, OIDC tokens, or an authenticating proxy. Only ServiceAccounts (the identity for in-cluster workloads) are true Kubernetes objects.

What’s the difference between the enforce, audit, and warn Pod Security Admission modes?

They’re independent and only enforce blocks. Under enforce, a Pod violating the standard is rejected. Under audit, the violation is recorded in the audit log but the Pod is still created. Under warn, the user gets a warning but the Pod is created. A Pod created despite a violation almost always means the namespace was in audit/warn, not enforce.

Are Kubernetes Secrets encrypted by default?

No. Secrets are only base64-encoded in etcd, which is trivially reversible. To actually protect them you must enable encryption at rest with an EncryptionConfiguration (ideally KMS-backed) and tightly scope RBAC so only the ServiceAccounts that need a Secret can read it.

Do Network Policies block traffic by default?

No. By default all Pods can communicate freely. A Network Policy only affects the Pods it selects — and once a Pod is selected by any policy, everything not explicitly allowed is denied. A common starting point is a default-deny policy (podSelector: {}) followed by targeted allow rules. Enforcement also requires a CNI plugin that supports Network Policies.

Ready to make Security Fundamentals a strength? Drill realistic, explained questions with the Sailor.sh KCSA mock exams, then map your full prep with the KCSA exam guide for 2026.