Last reviewed: May 2026
A scannable reference of architectural patterns the KCSA exam tests. Read top-to-bottom, or jump to a section.
Architecting a holistic cloud native security strategy.
Implement security controls across the 4Cs: Cloud (foundation), Cluster, Container, and Code.
Why: A compromise at an outer layer (e.g., Cloud) undermines the security of all inner layers. Security is as strong as its weakest link.
Protecting against single-point security failures.
Implement multiple, overlapping security controls at different layers (e.g., NetworkPolicies, RBAC, Security Contexts).
Why: If one control fails or is bypassed, other layers continue to provide protection, increasing attacker difficulty.
Securing network traffic in an environment where network location is not a trusted boundary.
Implement a "never trust, always verify" model. Authenticate and authorize every request, typically using a service mesh for mTLS.
Why: Assumes threats can exist both inside and outside the network, eliminating implicit trust based on network position.
Limiting the blast radius of a compromised identity or component.
Grant all subjects (users, service accounts, nodes) only the minimum permissions required to perform their function.
Why: Reduces the potential damage an attacker can cause with stolen credentials.
Reducing the cost and impact of security vulnerabilities.
Integrate automated security scanning (SAST, SCA, image scanning) and policy checks into the early stages of the CI/CD pipeline.
Why: Finds and fixes vulnerabilities earlier in the development lifecycle, when they are cheapest to remediate.
Protecting sensitive cluster data (especially Secrets) if etcd storage is compromised.
On the kube-apiserver, use `--encryption-provider-config` to enable encryption at rest for resources before they are stored in etcd.
Why: By default, Kubernetes Secrets are only base64 encoded in etcd. This provides true encryption on disk.
Preventing unauthorized access and eavesdropping on etcd communication.
Configure etcd with mTLS for both client (`--client-cert-auth`) and peer (`--peer-client-cert-auth`) communication.
Why: Ensures only authenticated components (apiserver, other etcd members) can communicate with etcd and that traffic is encrypted.
Preventing unauthenticated access to the Kubernetes API server.
Set the `--anonymous-auth=false` flag. Use strong authentication methods like OIDC or x509 certificates.
Why: Disables the `system:anonymous` user, forcing all requests to be authenticated and logged against a specific identity.
Requirement to track all changes and access attempts for security and compliance.
Enable API server audit logging with `--audit-policy-file` and ship logs to an external, immutable logging system.
Why: Provides an essential, tamper-evident trail for incident investigation, threat hunting, and compliance audits.
Reducing the attack surface of worker nodes.
Set kubelet flags: `--anonymous-auth=false`, `--authorization-mode=Webhook`, and `--read-only-port=0`.
Why: This enforces that all requests to the kubelet API are authenticated and authorized by the API server and disables the insecure, unauthenticated read-only port.
Preventing information leakage from control plane components.
Set the `--profiling=false` flag on kube-apiserver, kube-controller-manager, and kube-scheduler in production.
Why: Profiling endpoints can expose internal performance data and system details that could aid an attacker in reconnaissance.
Protecting control plane components from unauthorized network access.
Use firewall rules (cloud security groups, iptables) to restrict access to the API server (6443) and etcd (2379) ports to trusted sources only.
Why: Network-level access control is a foundational layer of defense, preventing attackers from even reaching sensitive component APIs.
Granting permissions to users or applications.
Use namespaced `Roles` over `ClusterRoles`. Grant specific verbs (`get`, `list`) instead of wildcards (`*`).
Why: Follows the principle of least privilege, limiting the scope of permissions to only what is necessary within a specific namespace.
A pod does not need to communicate with the Kubernetes API.
Set `automountServiceAccountToken: false` on the pod spec or the ServiceAccount itself.
Why: Prevents exposing unnecessary credentials inside the pod, reducing the attack surface if the pod is compromised.
Enforcing a baseline security posture for all pods in a namespace.
Use the built-in `PodSecurity` admission controller by applying namespace labels like `pod-security.kubernetes.io/enforce: baseline`.
Why: Provides a standardized, built-in way to prevent risky pod configurations (like privileged containers) without third-party tools.
Hardening individual container security to prevent privilege escalation.
In the pod spec, set `securityContext` fields: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Why: These controls prevent running as root, block mechanisms for gaining new privileges, and make the container filesystem immutable, drastically reducing the impact of a compromise.
Implementing a zero-trust network model within the cluster.
Apply a default-deny NetworkPolicy to each namespace that selects all pods (`podSelector: {}`) and has an empty ingress/egress rule list.
Why: Kubernetes networking is default-allow. This policy inverts the model to default-deny, forcing developers to explicitly allow required traffic.
Allowing traffic only between specific application tiers (e.g., web-to-api).
Create NetworkPolicies that use `podSelector` and `namespaceSelector` to define granular ingress and egress rules based on labels.
Why: Prevents lateral movement by attackers by ensuring a compromised pod can only communicate with explicitly authorized peers.
A user needs permission to `kubectl exec` into containers for debugging.
Grant the `create` verb on the `pods/exec` subresource in the relevant Role or ClusterRole.
Why: The `exec` action is unintuitively controlled by the `create` verb because it creates a new exec session. This is a common point of confusion.
An attacker gains access to a container and attempts to compromise the host node.
Forbid privileged containers (`securityContext.privileged: false`), host namespaces (`hostNetwork`, `hostPID`), and mounting the Docker socket.
Why: These configurations effectively break container isolation, giving a compromised container root-level access to the host.
Preventing the deployment of container images with known vulnerabilities or malicious code.
Implement image scanning (e.g., Trivy) and image signature verification (e.g., Cosign) in the CI/CD pipeline and via admission control.
Why: Provides a defense-in-depth approach: scanning catches known vulnerabilities, while signing verifies image integrity and provenance.
An attacker has compromised one pod and is attempting to access other pods in the cluster.
Implement default-deny NetworkPolicies and create specific allow rules only for required pod-to-pod communication.
Why: Restricts an attacker's "line of sight" from a compromised pod, containing the breach and preventing it from spreading.
Preventing a compromised pod from stealing cloud IAM credentials from the instance metadata service.
Apply a default-deny egress NetworkPolicy that explicitly blocks traffic to the metadata IP (e.g., `169.254.169.254/32`).
Why: This is a common attack path in cloud environments. Blocking this egress path mitigates the risk of IAM credential theft from pods.
Protecting against denial-of-service or cryptojacking attacks that exhaust node resources.
Apply `ResourceQuota` objects to namespaces to limit total resource usage and `LimitRange` objects to enforce limits on individual pods.
Why: Ensures that no single tenant or workload can starve others of resources, providing stability and preventing abuse.
An attacker attempts to maintain long-term access to a compromised cluster.
Monitor for the creation of unexpected `DaemonSets`, `CronJobs`, or privileged pods. Restrict permissions to create these resources.
Why: Attackers use these workload types to ensure their malicious code runs persistently, even if a node or pod is restarted.
Ensuring container images are free of known vulnerabilities before deployment.
Integrate an image scanner like Trivy, Clair, or Grype into the CI/CD pipeline to scan images and fail the build if critical vulnerabilities are found.
Why: Automates vulnerability detection early ("shift left"), preventing vulnerable code from reaching production.
Ensuring only trusted, unmodified container images are deployed to the cluster.
Sign images with a tool like Cosign in the CI pipeline. Use a validating admission controller (e.g., Kyverno, Gatekeeper) to verify the signature at deploy time.
Why: Provides cryptographic proof of image integrity (it has not been tampered with) and provenance (it came from a trusted source).
Detecting malicious activity inside a running container (e.g., shell spawned, sensitive file access).
Deploy a runtime security tool like Falco, which uses eBPF to monitor syscalls and alert on suspicious behavior based on a defined ruleset.
Why: Provides visibility into runtime activity, which static scanning and admission control cannot see. It is crucial for detecting active breaches.
Enforcing custom, organization-specific security policies (e.g., "all images must come from our corporate registry").
Use a policy engine like OPA Gatekeeper or Kyverno as a validating admission controller to enforce policies written in Rego or YAML.
Why: Allows for flexible, declarative, and automated enforcement of security policies that go beyond Kubernetes' built-in controls.
Encrypting and authenticating all service-to-service traffic within the cluster.
Implement a service mesh (e.g., Istio, Linkerd) to automatically provide mutual TLS (mTLS) for all meshed services.
Why: Achieves zero-trust networking by ensuring that all in-cluster traffic is encrypted and that services mutually verify each other's identity.
Running untrusted or multi-tenant workloads that require stronger isolation than standard containers.
Use a sandboxed container runtime like gVisor or Kata Containers, which provide an additional isolation layer between the container and the host kernel.
Why: Reduces the attack surface of the host kernel, making container escape significantly more difficult.
Fine-grained control over a container's permissions at the kernel level.
Use Seccomp profiles to filter allowed syscalls and AppArmor/SELinux profiles to enforce mandatory access controls (MAC) on file and network access.
Why: These Linux-native security features provide a deep layer of defense, restricting what a compromised container process can fundamentally do.
Reducing the attack surface within a container image.
Build application images using minimal or "distroless" base images that contain only the application and its direct dependencies.
Why: Removes shells, package managers, and other utilities that are unnecessary for production and could be used by an attacker after a compromise.
Verifying that a Kubernetes cluster is configured according to security best practices.
Regularly run `kube-bench`, an automated tool that checks the cluster against the CIS Kubernetes Benchmark.
Why: Provides a standardized, comprehensive, and automated way to audit cluster security posture and identify misconfigurations.
A cluster must process and store credit card data in compliance with PCI DSS.
Use NetworkPolicies for network segmentation to isolate the Cardholder Data Environment (CDE), and enable encryption at rest for etcd.
Why: These controls directly map to PCI DSS requirements for network segmentation (Req 1) and protection of stored cardholder data (Req 3).
A cluster handles Protected Health Information (PHI) and must comply with HIPAA.
Implement strict RBAC, enable comprehensive audit logging, and ensure data is encrypted both at rest and in transit.
Why: These controls address HIPAA's Technical Safeguards for access control, audit controls, and transmission security.
Ensuring audit logs are preserved for compliance and forensics, even if the cluster is compromised.
Configure the API server to stream audit logs to an external, write-once/immutable logging backend (e.g., a SIEM or a locked-down cloud storage bucket).
Why: Prevents an attacker with cluster-admin privileges from covering their tracks by modifying or deleting local audit logs.