KCSA key terms

A layered model that treats security as nested boundaries: the cloud or corporate infrastructure, the cluster, the containers, and the code running inside them. Weakness in an outer layer undermines every inner layer.

The division of security duties between a cloud provider and its customer. The provider secures physical facilities, hardware, and managed control planes; the customer secures workloads, identity, configuration, and data.

A cloud service where the provider operates the control plane, including the API server, etcd, and scheduler, while the customer manages worker nodes, workloads, and access configuration. Responsibility boundaries vary by offering and must be verified.

Practices that protect software from tampering between authoring and deployment, including dependency pinning, signed artifacts, provenance attestations, and admission checks that reject unverified images.

The front end of the Kubernetes control plane. It authenticates requests, enforces authorization and admission, validates objects, and is the only component that talks directly to etcd.

The distributed key-value store holding all cluster state, including Secrets. It should be reachable only from the API server, protected with TLS, and encrypted at rest because it contains sensitive data.

The node agent that registers the node, receives PodSpecs from the API server, and starts containers. Its API can execute commands in containers, so anonymous access and unauthenticated read ports must be disabled.

A node component that programs network rules so Service traffic reaches the correct Pods. Its configuration affects whether traffic can be intercepted or bypassed, and it must run with least privilege.

A special-purpose authorization mode granting kubelet identities only the permissions they need, such as reading secrets and services for Pods scheduled to their own node, rather than broad cluster read access.

Reducing attack surface on control plane hosts by disabling anonymous authentication, restricting the API server's network exposure, enabling audit logging, rotating certificates, and limiting access to etcd and admin kubeconfig files.

A record of API server requests, including who made each request, what object was touched, and the outcome. Audit policy rules control which events are recorded and at what level of detail.

The process of establishing who is making an API request, using client certificates, bearer tokens, service account tokens, or an external identity provider integrated through OpenID Connect or a webhook.

The mechanism deciding whether an authenticated identity may perform an action. Common modes are RBAC, webhook, and Node; requests are evaluated against enabled modes in order until one allows or denies.

Role-based access control, where Roles or ClusterRoles list allowed verbs on resources and RoleBindings or ClusterRoleBindings grant those permissions to users, groups, or service accounts.

A cluster-scoped grant that binds a ClusterRole to subjects across the whole cluster. Because it is not namespaced, it is a common source of excessive privilege and should be reviewed carefully.

An identity for processes running in Pods. Token mounting can be disabled, tokens can be bound to specific audiences and expiry, and each workload should have its own account rather than sharing the default.

An object holding sensitive data such as passwords or tokens. By default it is only base64-encoded, so protection depends on RBAC restrictions, encryption at rest, and avoiding exposure through environment variables or logs.

Three built-in policies, Privileged, Baseline, and Restricted, describing progressively stricter Pod requirements. They are enforced through the Pod Security admission controller using namespace labels.

A built-in admission controller that enforces Pod Security Standards on namespaces, with modes to reject violating Pods, record audit events, or emit warnings when a policy is breached.

Per-Pod or per-container settings controlling privilege and access, such as runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities, and seccomp profiles.

Fine-grained privileges that can be granted to or dropped from a process. Containers should drop all capabilities and add back only those strictly required, avoiding privileged mode entirely.

A container granted nearly all host capabilities, effectively removing isolation from the node. It can access devices and kernel interfaces, so it should be prohibited outside narrowly justified system workloads.

A plugin that intercepts requests after authentication and authorization but before persistence, able to mutate or validate objects. It enforces policy such as image registries, resource limits, and security settings.

An in-cluster mechanism using Common Expression Language to declare validation rules without running a webhook server, reducing the operational overhead and failure risk of external admission services.

A namespaced object selecting Pods and declaring allowed ingress and egress traffic. Enforcement requires a compatible CNI plugin; without one the object is stored but has no effect.

The component providing Pod networking, IP address management, and often policy enforcement. Whether NetworkPolicy is honored depends entirely on the chosen plugin's capabilities.

A structured description of assets, adversaries, trust boundaries, and attack paths for a system. For Kubernetes it typically covers compromised containers, exposed API servers, credential theft, and lateral movement.

A threat classification scheme covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, useful for systematically enumerating risks in cluster components.

A chain of weaknesses an adversary follows from an initial foothold to a goal, such as a vulnerable Pod leading to stolen service account tokens and then cluster-admin permissions.

Techniques an attacker uses to move from one compromised workload or node to others, often through over-permissive network reachability, shared credentials, or mounted service account tokens.

Gaining permissions beyond those originally granted. In Kubernetes this includes creating Pods that mount host paths, using privileged containers, or exploiting RBAC rules that allow escalating verbs.

Monitoring runtime behavior and audit events to identify malicious activity, such as unexpected process execution, shell access in containers, or unusual API calls, and alerting responders quickly.

Controls that observe and restrict behavior while workloads run, including system call filtering, file integrity monitoring, and detection of anomalous process or network activity inside containers.

A Linux facility that filters system calls a container may make. A well-chosen profile blocks dangerous calls and shrinks kernel attack surface; RuntimeDefault is a common baseline.

Cryptographically signing container images so consumers can verify origin and integrity. Admission controllers can then reject images lacking a valid signature from a trusted identity.

Automated inspection of images and running workloads against known vulnerability databases. Effective programs scan in CI, at admission, and continuously in the registry to catch newly disclosed flaws.

Consensus configuration hardening guidance published for Kubernetes, operating systems, and cloud platforms. Assessment tools compare live settings against these recommendations and report deviations.

A structured examination producing evidence that controls operate as described. For Kubernetes, evidence includes configuration snapshots, audit logs, access reviews, and policy enforcement reports.

Granting only the permissions required for a task and no more. Applied to Kubernetes, it means narrow Roles, dedicated service accounts, and no standing cluster-admin access for routine work.

Encrypting stored data so disk or backup access does not reveal contents. For Kubernetes this is configured on the API server for Secret and other resources written to etcd.