KCSA quick review

Memory hook: Cloud contains cluster; cluster contains containers; containers execute code.

Must remember

Security follows the 4Cs: Cloud, Cluster, Container, Code. Each inner layer depends on outer layers, so a patched application cannot compensate for a stolen cloud administrator credential. Apply several independent controls: reduce the chance of compromise, limit its reach, detect it and recover.

Shared responsibility changes with the service. A provider may operate a managed control plane; the customer still owns application data, workload configuration and granted permissions. Check who operates worker nodes, patches each layer, holds encryption keys and retains logs. Managed Kubernetes does not automatically make a public application private.

The CIA triad asks whether data stays confidential, changes are trustworthy and service remains available. Least privilege restricts each identity to required actions and duration. Zero trust verifies identity and authorization even for internal traffic; network location alone is not identity.

Preventive controls stop or constrain an action, such as admission rejecting privileged Pods. Detective controls reveal it, such as an alert on unexpected API access. Corrective controls restore a safe state, such as revoking a leaked credential and redeploying a clean workload. Administrative controls include training and approved procedures; technical controls implement system behavior; physical controls protect facilities and equipment.

Linux namespaces separate views of processes, mounts or networks; cgroups account for and constrain resources. These are different from Kubernetes namespaces, which organize API objects. Containers usually share a host kernel; they are not equivalent to virtual machines. Stronger isolation may require sandboxed runtimes, dedicated nodes or separate clusters according to the trust model.

Application controls remain necessary: validate untrusted input, parameterize database queries, enforce authorization for each request and avoid hard-coded credentials. SAST examines source; DAST exercises a running application; dependency analysis identifies risky third-party components. None guarantees absence of defects.

Choose under exam pressure

Traps

• A Kubernetes namespace is neither a VM nor an automatic firewall.
• Provider-managed infrastructure does not transfer responsibility for application authorization.
• Zero trust does not mean every request is denied; it means trust is explicitly established and bounded.

Practise this topic

Memory hook: Inventory tells what; provenance tells how; signatures tell who; scanning finds known risk.

Must remember

An image is a packaged filesystem and execution configuration. A tag is a movable name; a digest identifies particular content. Pin reviewed production artifacts by digest to prevent an unchanged tag from silently referring to another image. Digest pinning gives stable identity, not proof that the image is safe.

Protect each supply-chain step: source repository, dependency resolution, build runner, registry and deployment. Require reviewed source changes, limited build credentials and separation between untrusted pull requests and privileged release jobs. Rebuild and redeploy patched images through a controlled pipeline instead of repairing containers manually and losing the change on restart.

SLSA provides supply-chain assurance requirements with increasing guarantees. Understand the purpose of trustworthy builds and provenance rather than memorizing a tool as a universal compliance solution. Sigstore/Cosign can sign and verify artifacts; verification must constrain the expected signing identity or trusted key, including the issuer when identity-based verification is used.

A registry stores and distributes images; make private artifacts available only to authorized readers. Separate push from pull permissions, limit retention and protect robot credentials. Use TLS for registry connections. imagePullSecrets support authenticated pulls in their namespace; they do not authorize application requests or prove image provenance. Approved registry policies and signature verification can be enforced during admission.

Prefer maintained minimal base images, a non-root application user and only required packages. Multi-stage builds can leave compilers and build tools out of the final image. Secrets copied into an image layer may remain recoverable even if a later layer deletes the file; use an appropriate build secret mechanism and never publish credentials in the image.

A vulnerability needs triage: affected version, exposure, exploitability, business impact and compensating controls. Record approved exceptions with an owner and expiry. Continue scanning stored and running artifacts as new vulnerabilities become known. Keep dependency licensing and provenance evidence where supply-chain policy requires them.

Choose under exam pressure

Traps

• A private registry can contain malicious or outdated artifacts.
• ImagePullPolicy Always does not establish that the selected image is trusted.
• A clean scan is a point-in-time result, not a guarantee against future disclosures or malicious logic.

Practise this topic

Memory hook: The API admits; controllers reconcile; the scheduler places; etcd remembers.

Must remember

The API server is the normal entry point for cluster management. Protect its reachable endpoints, validate TLS certificates and configure authentication, authorization and admission. A typical write request establishes identity, checks permission and passes applicable admission/validation before persistence. API audit logs provide evidence of requests. Direct access to etcd or node endpoints can bypass some API protections, so protect those separately.

The controller manager runs reconciliation loops that move observed state toward desired state. A controller may create Pods or update other resources with its own credentials. Scope those credentials to its responsibility and protect its configuration, credentials and serving endpoints. Installing an operator also installs a controller with whatever permissions its manifests grant; review them.

The scheduler selects a node for an unscheduled Pod according to constraints and available resources. It does not run containers itself. Protect scheduler configuration, plugins, credentials and access to its endpoints. A malicious scheduler or privileged configuration change can place workloads on unsuitable nodes or disrupt availability. Scheduling isolation depends on who can set node labels, taints and workload placement constraints.

Etcd stores Kubernetes API data, including sensitive objects. Restrict client and peer network access, authenticate and encrypt connections, protect files and snapshots, and configure API storage encryption where needed. API encryption at rest and transport TLS solve different problems. A copied etcd snapshot can expose information; secure and test backups rather than placing them in a broadly readable bucket. Encryption also requires protection and recoverability of the associated keys.

The user-facing client is part of the trust boundary. A kubeconfig can contain tokens, private-key references, server addresses and executable credential plugins. Treat an untrusted kubeconfig as potentially dangerous; inspect its source and configuration before using it. Protect local credential files and avoid insecure-skip-tls-verify, which weakens server identity validation.

Check context and namespace before inspecting or changing a cluster. Use separate least-privilege identities for users and automation, short-lived credentials where supported, and a controlled identity-provider login process. Never distribute the cluster-admin kubeconfig as a convenience.

Read-only recognition drill: kubectl config current-context identifies the selected cluster/user context; kubectl get --raw=/version reports API version if permitted. A successful API request establishes neither that all component endpoints are secure nor that the caller should have administrator access.

Choose under exam pressure

Traps

• Exposing only an authenticated API does not make an independently exposed etcd endpoint safe.
• Controller permissions can be much broader than an ordinary application service account.
• TLS server validation must remain enabled; encryption to an impersonator is not sufficient.

Practise this topic

Memory hook: The node owns the kernel; the Pod shares a network; access to either changes the blast radius.

Must remember

The kubelet manages assigned Pods on a node and talks to the runtime through CRI. Protect its HTTPS API with authentication and authorization, restrict network access and avoid anonymous or obsolete unauthenticated endpoints. A user who can reach a powerful kubelet endpoint may bypass protections assumed at the normal API entry point.

The container runtime starts containers and interacts closely with the host. Keep runtime and host packages patched, minimize installed services and tightly protect runtime sockets. Mounting a container-management socket into an application can expose powerful host operations; it is not just another harmless file mount.

A Pod is the scheduling unit. Its containers share a network namespace/IP and can talk over localhost; they can share configured volumes. This makes a sidecar part of the workload's trust boundary. Processes are not automatically placed into one shared PID namespace unless configured. Privileged mode, host PID/network namespaces and writable hostPath mounts can erode isolation and expose node resources.

Kube-proxy implements Service forwarding behavior on nodes in common cluster designs. Some network implementations replace that function. It is neither the container runtime nor the mechanism that automatically enforces every NetworkPolicy. CNI integration supplies Pod networking; policy enforcement depends on a capable implementation. Protect network agents because they often need elevated host access. DNS resolution, Service selection and policy enforcement are separate steps.

Storage security includes both API permission and access to the actual backend. A PVC requests storage; a PV represents it; CSI drivers connect Kubernetes to storage systems. Apply filesystem permissions, appropriate mount settings, backend authorization and encryption in transit/at rest as supported. A PVC access mode describes mount capability, not an authorization policy: ReadWriteOnce does not mean only one person or Pod can read the data.

Persistent data and snapshots may outlive a Pod. Reclaim policy Retain leaves backing storage for managed reuse or cleanup; Delete can remove the backing asset depending on the provisioner. Backups need their own access, retention and recovery controls. Avoid placing confidential data on broadly accessible hostPath volumes and understand which administrators can access node disks.

Resource boundaries also protect availability. Requests guide scheduling; limits constrain supported resource consumption. ResourceQuota limits aggregate namespace consumption and object counts; LimitRange can supply/enforce per-object resource rules. CPU throttling and memory termination are different outcomes. Limits reduce noisy-neighbor risk but do not replace application rate limiting or denial-of-service protection.

Choose under exam pressure

Traps

• Containers inside one Pod are not mutually isolated network tenants.
• RWO is a storage attachment/access capability, not a data confidentiality control.
• An authenticated Kubernetes API does not secure an independently exposed kubelet API.
• Deleting a Pod does not reliably delete its persistent data or snapshots.

Practise this topic

Memory hook: Authenticate who, authorize what, protect the secret, record the request.

Must remember

Authentication identifies the caller. Kubernetes can use supported client certificates, bearer tokens and integrations such as an OIDC identity provider. Normal human users are typically managed outside the Kubernetes API; ServiceAccounts are Kubernetes objects providing workload identities. A token is a credential, not a grant of unlimited permissions.

Prefer short-lived, audience-bound projected service-account tokens over manually issued long-lived token Secrets. Disable automatic token mounting where a workload does not need API access. Give each application an appropriate identity instead of sharing a privileged ServiceAccount. Cloud workload identity integrations can exchange trusted workload identity for scoped cloud access; Kubernetes RBAC and cloud IAM remain separate permission systems.

Authorization decides whether the identity can perform the requested operation. With RBAC, permissions are additive allow rules: verbs such as get/list/watch/create on resources and API groups. A Role defines namespaced permissions; a binding grants them to subjects. A ClusterRole can describe namespaced or cluster-scoped permissions. A RoleBinding can bind a ClusterRole's applicable permissions within one namespace; a ClusterRoleBinding grants its permissions across the cluster. There is no RBAC deny rule that overrides an existing allow grant.

Avoid wildcard resources/verbs and routine cluster-admin access. Permission to create Pods may indirectly expose Secrets or powerful ServiceAccounts available to those Pods. Permission to bind roles, escalate privileges or impersonate identities also deserves special review. kubectl auth can-i get secrets -n team-a checks a particular permission for the selected identity; it does not prove there is no indirect escalation path.

Secrets separate sensitive values from ordinary configuration, but base64 is encoding, not encryption. Kubernetes does not automatically guarantee encrypted etcd storage; configure and verify encryption at rest. Restrict Secret API access and which containers receive each secret. List/watch can expose Secret contents, not just names. Avoid secrets in images, Git, command history, crash reports and application logs. Rotate a leaked value and update consumers; deleting its Kubernetes object does not revoke credentials issued by another system.

Audit logging records API activity according to a policy. Levels are None, Metadata, Request and RequestResponse. Metadata captures who, action, target and timing without request/response bodies; body logging can expose sensitive content. Audit stages describe request progress, including receipt and completion. Protect log access, forward evidence beyond the workload's control and choose retention appropriate to the investigation requirements. Application logs and API audit logs answer different questions.

Choose under exam pressure

Traps

• A valid credential can still lack permission; TLS, authentication and authorization are distinct checks.
• Base64 and encrypted network transport do not establish encryption at rest.
• Preventing direct get Secret access may be insufficient if the same identity can create Pods that mount it.
• Audit RequestResponse is not automatically the safest level because it can retain sensitive bodies.

Practise this topic

Memory hook: Admission decides what enters; runtime settings constrain it; network policy limits where it talks.

Must remember

Pod Security Standards (PSS) define three policy levels. Privileged allows broad permissions; Baseline blocks common escalation paths while remaining broadly compatible; Restricted adds stronger hardening requirements. The standard describes permitted configuration; it is not itself a container runtime or network firewall.

Pod Security Admission (PSA) is the built-in mechanism for applying PSS with namespace labels. Modes are enforce (reject violations), audit (record violations in audit annotations) and warn (tell the requesting user). Modes can use different levels and version labels, such as enforcing baseline while warning about restricted. Restrict who may modify policy labels or exemptions. Admission does not retroactively evict every existing noncompliant Pod.

Recognize relevant Linux security settings: runAsNonRoot requires a non-root identity; allowPrivilegeEscalation: false restricts gaining more privilege through execution; capability dropping reduces Linux privileges; seccomp restricts system calls; AppArmor/SELinux constrain permitted operations through security profiles. A read-only root filesystem limits filesystem changes but requires planned writable locations. These controls complement each other. Privileged containers bypass important protections. The exact PSS checks vary with policy version and operating system; do not assume read-only root filesystem is a universal Restricted requirement.

Admission operates after authentication/authorization on applicable API operations. Mutating admission may adjust an object; validating admission can reject it. Policies can require approved registries, image signatures or organizational labels. Webhook credentials, TLS, permissions, availability and failure policy matter: fail-open can admit unchecked changes; fail-closed can block legitimate changes during an outage. Admission does not scan every network packet or continuously evaluate all running processes.

NetworkPolicy selects Pods and controls allowed ingress and/or egress. A compatible network implementation must enforce it. Pods are ordinarily non-isolated in a direction until a policy selects them for that direction. Allowed traffic is the union of applicable policies. If both ends are isolated, the source's egress and destination's ingress must both permit the connection; allowed replies are handled as part of that connection.

Within one peer entry, namespaceSelector plus podSelector means both must match. Separate peer entries are alternatives. A Pod selector alone selects peers in the policy's namespace. Be deliberate about empty selectors and allow DNS when restricting egress. Standard NetworkPolicy is primarily L3/L4 policy, not HTTP user authorization or automatic encryption.

A namespace gives administrative scope; segmentation requires RBAC, network policy, admission, quotas and appropriate node/runtime boundaries together. Strongly hostile tenants may require separate clusters or stronger isolation than shared namespaced workloads.

Choose under exam pressure

Traps

• Warn and audit do not reject a Pod merely because it violates their level.
• NetworkPolicy YAML has no enforcement effect without a supporting network plugin.
• An ingress allow at the destination does not override a denying source egress policy.
• PSS Restricted does not automatically mean every possible hardening setting is enabled.

Practise this topic

Memory hook: Draw the boundary, follow the identity, then limit persistence and movement.

Must remember

A threat model explains what needs protection, who can attack it, how data and control cross boundaries, and which controls reduce risk. Start with a simple data-flow diagram: user to application; developer/CI to registry and API; API to etcd and nodes; workload to database, DNS, identity service and external endpoints. Identify trust changes at every crossing, including tenant-to-tenant and container-to-host boundaries.

Threat is a possible harmful event or actor; vulnerability is a weakness; risk combines likelihood and impact in context. A published CVE matters differently for an unreachable unused component and an exposed execution path. An attack surface includes endpoints, credentials, dependencies, configuration and people, not only public IP addresses.

Persistence is not persistent storage. It is an attacker's ability to retain or regain access. Deleting one malicious Pod may fail because a controller recreates it or stolen credentials still work. Investigate the authorized owner and configuration source; remove the persistence mechanism and revoke compromised access as part of recovery.

A container compromise is not automatically a host compromise, but shared kernels and dangerous settings can permit escalation. Similarly, a stolen service-account token is constrained by its permissions only if other paths, such as creating a Pod under a stronger identity, are also controlled. Think in chains rather than one isolated control.

STRIDE prompts six questions: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. MITRE ATT&CK for Containers catalogs observed adversary techniques and tactics. STRIDE helps ask what could go wrong; ATT&CK helps organize recognizable attacker behavior. Neither tool automatically measures or eliminates every risk.

During response, follow an agreed plan: validate the signal, preserve relevant evidence, contain exposure, remove persistence, rotate affected credentials, rebuild from trusted artifacts and verify recovery. Keep investigation evidence outside the compromised workload's control. Choose containment with awareness of availability and evidence loss; indiscriminate deletion can hide the original cause.

Choose under exam pressure

Traps

• Network location does not prove workload identity.
• An ephemeral container can still steal persistent credentials or create durable API objects.
• Fixing one visible symptom does not remove every step in the attack chain.
• Security response should preserve useful evidence before destructive recovery steps where feasible.

Practise this topic

Memory hook: Observe the action, authenticate the peer and authorize the connection.

Must remember

Metrics summarize numeric behavior over time, such as API errors, resource saturation or authentication failures. Logs record individual events. Traces connect spans of a request across services. Together they help distinguish a slow dependency, network rejection, application failure and malicious behavior. A graph alone rarely identifies who changed a permission; API audit logs are designed for that question.

Runtime monitoring examines behavior after deployment. Tools such as Falco can detect suspicious execution or file/network activity using configured event sources and rules. Image scanning answers questions about artifact contents; runtime detection answers questions about current behavior. Neither replaces the other. Tune rules, preserve context and connect alerts to an owner and response procedure.

Protect observability infrastructure: restrict access, authenticate agents, encrypt transport and retain evidence in a system the workload cannot freely modify. Redact credentials and sensitive payloads. Avoid unbounded or secret-bearing metric labels; they can expose data and produce excessive cardinality. Accurate clocks and stable workload/identity metadata make evidence easier to correlate.

PKI connects public keys to identities through certificates and trusted certificate authorities. A TLS client validates an appropriate trust chain, identity/SAN and certificate validity period. Protect private keys, restrict certificate issuance and rotate credentials before expiry. A certificate is normally public; its private key must remain private. Encryption without identity verification is vulnerable to impersonation.

With ordinary server-authenticated TLS, the client verifies the server. With mutual TLS, both ends authenticate using certificates. This supplies peer identity and protects transport; it does not inherently grant permission to call every API. Authorization policy still decides which identity may perform which operation. TLS termination at an ingress also does not automatically encrypt the onward connection to a backend.

A service mesh can supply workload identity, mTLS, traffic policy and telemetry across participating workloads. Its control plane distributes configuration/identity material; its data plane enforces applicable traffic behavior. Mesh coverage and configuration matter: workloads outside the managed path may not receive the same guarantees. Application-level user authorization, node hardening and network policy remain separate concerns.

Plan connectivity deliberately. Limit management endpoint reachability; use controlled private access paths where appropriate. North-south traffic crosses the environment edge; east-west traffic flows among services. Restrict ingress and egress separately, protect DNS resolution and allow only required destinations. A private address, ClusterIP Service or NAT path does not automatically provide encryption, identity or authorization. Validate the actual traffic path and effective policies instead of trusting a diagram alone.

Choose under exam pressure

Traps

• A mesh installed in the cluster does not imply every path is covered or mTLS is enforced.
• A certificate expiry alert is an availability control as well as a credential-lifecycle concern.
• TLS at the load balancer does not establish end-to-end encryption.
• Logs can become a sensitive data store and require their own permissions.

Practise this topic

Memory hook: A framework sets direction; a benchmark checks configuration; evidence proves the control ran.

Must remember

Compliance means satisfying applicable obligations and agreed controls within a defined scope. Security is the broader practice of reducing risk. Passing a configuration scan is evidence about particular checks at a particular time, not proof that an entire organization or application is secure or compliant.

Map obligations to assets, owners, controls and evidence. For sensitive data, that can include restricted access, protected transport/storage, retention decisions, audit records and tested recovery. Privacy or payment-card obligations depend on the data, system and jurisdiction. The exam decision is to identify the applicable control and responsible owner, not assume every workload has the same legal scope.

Threat-modeling frameworks guide repeatable reasoning. Draw assets, entry points, data flows and trust boundaries, identify plausible threats, select mitigations, then validate and update the model as the system changes. Risk scoring aids prioritization but does not remove uncertainty or replace a documented treatment decision.

Supply-chain compliance needs traceable evidence: reviewed source, approved dependencies/licenses, inventory/SBOM, vulnerability decisions, artifact signatures/provenance and authorized deployment records. Bind evidence to a specific artifact digest or release. An unsigned spreadsheet claiming a release was scanned is weaker evidence than verified machine-generated records tied to the deployed artifact.

Automation makes checks repeatable. Kube-bench checks configuration against supported CIS benchmarks; scanners such as Trivy inspect supported artifacts/configuration for known findings. OPA/Gatekeeper or Kyverno can implement admission policy, with capabilities depending on configuration. Falco detects runtime behavior. These tools serve different stages; none alone provides a complete assurance program.

Treat policy as code like application code: version control, peer review, positive and negative tests, gradual rollout, monitored operation and explicit rollback. Detect drift between approved configuration and live state. Give the enforcement tools limited permissions and protect their supply chain too. Track exceptions with a justification, owner, review date and compensating controls; an unbounded bypass quietly becomes permanent policy.

Evidence should identify what was checked, when, against which control version, the result and any remediation. Protect its integrity and access. Periodically verify that alerts route to a person, failed controls are resolved and restored systems actually work. Continuous evidence is more useful than a one-time dashboard with no follow-up.

Choose under exam pressure

Traps

• Certification of a management system is not a claim that every technical component is invulnerable.
• A scanner may not be able to inspect provider-managed components; record that scope limitation.
• Audit evidence has to be protected from modification by the subjects being audited.
• Framework names are not interchangeable: governance, configuration, threats and supply chain answer different questions.

Practise this topic