CKS key terms

A Kubernetes object that selects pods and declares which ingress and egress traffic they may accept or send, expressed as rules over labels, namespaces, IP blocks and ports. Enforcement requires a CNI plugin that supports policies; otherwise the object is stored but ignored.

The cluster networking component that wires pod interfaces, assigns pod IPs and routes traffic between nodes. Policy-capable plugins such as Calico or Cilium also implement NetworkPolicy enforcement, so the plugin choice determines whether network restrictions actually work.

A NetworkPolicy that selects pods with an empty pod selector and declares both ingress and egress policy types with no rules, so all traffic to and from those pods is blocked unless another policy explicitly allows it.

Configuring an Ingress resource with a TLS section that references a Secret holding a certificate and key, so the ingress controller serves HTTPS for the listed hosts and client traffic is never plaintext at the edge.

A consensus-based checklist of configuration recommendations for the control plane, worker nodes and cluster policies, published by the Center for Internet Security. It is the reference against which cluster hardening is measured.

An open-source scanner that checks a cluster's control plane and node configuration against the CIS Kubernetes Benchmark and reports passes, failures and checks that require manual review, grouped by section.

A kube-apiserver configuration file listing providers such as aescbc, aesgcm or a KMS endpoint, used with --encryption-provider-config so Secret objects are encrypted at rest in etcd rather than stored as plain base64.

Blocking pods from reaching the cloud provider's instance metadata service at 169.254.169.254, typically with a NetworkPolicy or a metadata proxy, so a compromised container cannot steal node credentials.

A namespaced RBAC object listing rules of apiGroups, resources and verbs that grant permissions inside one namespace. It has no effect until bound to a subject with a RoleBinding.

A cluster-scoped RBAC object with the same rule structure as a Role but usable cluster-wide, for cluster-scoped resources, or as a reusable definition that RoleBindings can reference inside namespaces.

A namespaced object that grants the permissions of a referenced Role or ClusterRole to users, groups or service accounts, limited to the namespace where the binding itself is created.

A cluster-scoped binding that grants a referenced ClusterRole to subjects across the whole cluster, which makes it a frequent target when reviewing for privilege escalation.

Granting each identity only the verbs, resources and namespaces it actually needs, and nothing broader. It applies to RBAC rules, service accounts and container permissions to shrink the blast radius of a compromise.

A pod field, automountServiceAccountToken, that controls whether the API credential is projected into containers. Setting it false on pods that never call the API removes a ready-made token from an attacker who lands in the container.

An admission controller that limits what kubelet credentials can do, so a node identity may only modify its own Node object and pods bound to it, reducing damage when a node is compromised.

An API server mode enabled by --anonymous-auth that lets unauthenticated requests proceed as system:anonymous. Disabling it forces every caller to present a valid credential before authorization is evaluated.

A Linux Security Module policy loaded on the node that restricts a process to allowed file paths and capabilities. In Kubernetes it is selected per container through an annotation or the securityContext field.

A system call filter applied to a container, choosing RuntimeDefault, Unconfined, or a custom profile file present on the node, which limits which kernel calls the process is allowed to make.

Fine-grained kernel privileges that can be dropped from a container, for example dropping ALL and adding back only NET_BIND_SERVICE, so root inside the container cannot perform most privileged operations.

A container with privileged set to true that receives nearly all host capabilities and device access. It largely defeats isolation, so admission policies should block it outside tightly controlled namespaces.

A volume that mounts a directory or file from the node's filesystem into a pod. It can expose node credentials or allow writes into the container runtime, so pod security and admission policies restrict it.

Pod settings that place a container in the node's process or network namespace, letting it see node processes or bind host ports. They are common escalation paths and are restricted by Pod Security Standards.

Three built-in policy levels, privileged, baseline and restricted, describing progressively stricter pod requirements such as dropping capabilities, forbidding host namespaces and requiring non-root execution.

The built-in admission controller that enforces Pod Security Standards on namespaces through labels such as pod-security.kubernetes.io/enforce, with the modes enforce, audit and warn available per namespace.

A container securityContext flag that mounts the container's root filesystem read-only, preventing an attacker from writing binaries or modifying configuration inside a running container.

A pod or container securityContext field that makes the kubelet refuse to start the container if its image would run as UID 0, forcing an explicit non-root user.

The pod- and container-level fields that set user and group IDs, capabilities, seccomp and AppArmor profiles, read-only root filesystem and privilege escalation rules for a workload.

An admission controller that evaluates constraint templates written in Rego against API requests, letting a cluster reject workloads that violate organizational policy, such as privileged mode or missing resource limits.

Mutual TLS where both client and server present certificates, usually issued and rotated by a mesh control plane, so pod-to-pod traffic is encrypted and authenticated even inside the cluster network.

A cluster object naming a container runtime and its overhead, so a pod can request a sandboxed runtime such as gVisor or Kata Containers for stronger workload isolation from the host.

Referencing an image by its sha256 digest instead of a mutable tag, which guarantees the exact bytes that were scanned and approved are the bytes that actually run.

A tool that signs container images and stores the signature alongside the image in a registry, so admission controllers and CI pipelines can verify provenance before a workload is deployed.

A software bill of materials listing the components and versions inside an image, used to trace vulnerable dependencies and to satisfy supply chain attestation requirements.

Inspecting image layers against a database of known CVEs, typically in CI or in a registry scanner, to block or flag deployments that contain exploitable packages.

A pod field referencing a Secret that holds registry credentials, allowing the kubelet to pull from a private registry instead of relying on anonymous access to public images.

A kube-apiserver configuration that defines rules matching requests by user, verb, resource or namespace and assigns each match an audit level: None, Metadata, Request or RequestResponse.

A destination for audit events, either a rotating log file or a webhook that posts events to an external collector, configured with --audit-log-path and related flags or a webhook kubeconfig.

A runtime security tool that consumes kernel events through a driver and evaluates them against rules, alerting on suspicious behavior such as a shell spawned inside a container or writes to sensitive paths.

Mounting a path such as /run/containerd/containerd.sock into a pod, which gives the workload effective control of the node's container runtime and amounts to root on the host.