# Kubernetes Security Glossary and Term Map

> **Why this page exists:** the main glossary now spans the full Product Security program, but Kubernetes introduces a dense cluster of platform-specific words that are easier to learn together. This page keeps the cloud-native terms in one place.

> **Editorial note:** this page was seeded from the public Kubernetes Security Guide glossary at `k8s-security.guru/glossary/` and then normalized against the official Kubernetes glossary and CNCF cloud-native terminology so the wording stays practical and vendor-neutral.

## Best external glossaries to keep nearby

* Kubernetes Security Guide glossary: <https://k8s-security.guru/glossary/>
* Official Kubernetes glossary: <https://kubernetes.io/docs/reference/glossary/>
* CNCF cloud native glossary: <https://glossary.cncf.io/>

## Core cluster and control-plane terms

| Term                 | Plain-English meaning                                                                          | Why Product Security cares                                                                                         | Read next                                    |
| -------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- |
| Control plane        | The administrative brain of the cluster: API server, scheduler, controllers, and usually etcd. | Whoever controls the control plane can reshape cluster trust, workload placement, and policy.                      | API server hardening; etcd backup; admission |
| Admission controller | A validation or mutation checkpoint in the API write path.                                     | This is where mature platforms block unsafe images, missing labels, or prohibited pod settings before deploy.      | PSA; Kyverno; Gatekeeper                     |
| Namespace            | A logical boundary for names and often for ownership, quotas, and policy rollout.              | Namespaces are not hard multi-tenant isolation, but they are a critical blast-radius and governance unit.          | tenancy; RBAC; network policy                |
| Service account      | The identity used by a pod or controller inside the cluster.                                   | Workload identity mistakes often start with overpowered or reused service accounts.                                | workload identity; projected tokens          |
| RBAC                 | Role-Based Access Control for Kubernetes API actions.                                          | The fastest way to lose control of a cluster is to give broad list/get/update permissions to the wrong principals. | least privilege; cluster-admin               |
| NetworkPolicy        | A Kubernetes resource that limits which pods may talk to which other pods.                     | Without policy, east-west traffic is often wider than teams think.                                                 | default deny; segmentation                   |
| Audit logging        | Records of API activity and security-relevant changes in the cluster.                          | Needed for investigations, privileged-user oversight, and evidence collection.                                     | immutable logging; runtime investigation     |

## Pod and workload isolation terms

| Term                         | Plain-English meaning                                                                                         | Why Product Security cares                                                                         | Read next                                 |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| securityContext              | Pod or container settings for user/group IDs, privilege, seccomp, capabilities, and related runtime controls. | Many avoidable escapes and privilege escalations begin with weak `securityContext` defaults.       | restricted profile; seccomp; capabilities |
| Pod Security Standards (PSS) | The Kubernetes policy levels Privileged, Baseline, and Restricted.                                            | Gives teams a common vocabulary for what “acceptable pod posture” means.                           | PSA; exceptions                           |
| Pod Security Admission (PSA) | Namespace-level enforcement of Pod Security Standards.                                                        | A built-in baseline control for blocking obviously unsafe pod specs.                               | PSS rollout; namespace labels             |
| seccomp                      | Linux syscall filtering for processes.                                                                        | Reduces what a compromised process can ask the kernel to do.                                       | AppArmor; SELinux                         |
| AppArmor                     | Path/profile-based Linux restrictions on process behavior.                                                    | Useful for workload confinement where the underlying node OS supports it.                          | seccomp; securityContext                  |
| SELinux                      | Label-based mandatory access control for Linux.                                                               | Common on enterprise Linux platforms and strong for pod-level containment when configured well.    | labels; type enforcement                  |
| Capabilities                 | Fine-grained Linux privileges such as `NET_ADMIN` or `SYS_ADMIN`.                                             | Excess capabilities regularly undermine otherwise “non-root” containers.                           | least privilege; rootless                 |
| RuntimeClass                 | Mapping of a pod to a runtime configuration such as a sandboxed runtime.                                      | Helps apply stronger isolation to specific workload classes without redesigning the whole cluster. | gVisor; Kata; sandboxing                  |
| gVisor                       | A sandboxed container runtime that interposes on syscalls for stronger isolation.                             | Useful where workload risk justifies extra performance/operational trade-offs.                     | RuntimeClass; sandboxing                  |

## Supply chain, secrets, and runtime terms

| Term           | Plain-English meaning                                                                                    | Why Product Security cares                                                                             | Read next                            |
| -------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| Image signing  | Verifying that a container image came from the expected producer and was not tampered with.              | Important when promotion and deployment should trust only approved artifacts.                          | Cosign; provenance; attestations     |
| Provenance     | A verifiable record of how the image or artifact was built.                                              | Needed when you want more than “the digest matches” and need build-path evidence.                      | SLSA; secure build factory           |
| Secret         | Confidential material such as credentials, tokens, or keys.                                              | Teams often store too many long-lived secrets in clusters that should instead use workload identity.   | External Secrets; Vault; KMS         |
| Runtime signal | An event observed while the workload is running, such as a suspicious exec or unexpected capability use. | Runtime signals are how many container intrusions are noticed in practice.                             | Falco; eBPF; detections              |
| Containment    | A deliberate action to reduce attacker freedom during an incident.                                       | In Kubernetes this may mean isolate namespace traffic, freeze rollout, revoke tokens, or cordon nodes. | investigation playbook; blast radius |

## Five practical interpretation rules

1. **Pod-level hardening is necessary but not sufficient.** Weak workload identity or cluster-admin rights can bypass “good pod posture.”
2. **Namespace is a governance unit, not magical isolation.** Treat it as a policy and ownership boundary, not as a guaranteed tenant boundary.
3. **Admission and runtime solve different problems.** Admission stops bad intent from being deployed; runtime helps detect or contain what still happens.
4. **Signing without provenance is only partial trust.** You often need both “who signed this” and “how was it built.”
5. **A service account is an identity, not just a YAML field.** Review it the same way you would review a privileged IAM role.

## Suggested reading path

1. Official Kubernetes glossary for canonical core terms.
2. This page for Product Security translation.
3. [Container / Kubernetes / Platform Security — Images, Admission, RBAC, Pod Hardening, Isolation, and GitOps / Deployment Plane](https://github.com/D3One/Product-Security-Gitbook/blob/main/09-container-and-kubernetes-security/container-kubernetes-platform-security-images-admission-rbac-pod-hardening-isolation-and-gitops-deployment-plane.md)
4. [Container Isolation — seccomp, SELinux, AppArmor, Capabilities, gVisor, and Namespaces](https://github.com/D3One/Product-Security-Gitbook/blob/main/09-container-and-kubernetes-security/container-isolation-seccomp-selinux-apparmor-capabilities-gvisor-and-namespaces.md)
5. [Cloud / Kubernetes Runtime Investigation Playbooks and Containment Templates](/attack-paths-testing-detection-and-hardening/index/cloud-and-kubernetes-runtime-investigation-playbooks-and-containment-templates.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-glossary-and-term-map.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.