Kubernetes Security: Control Design and Evidence
Design Kubernetes identity, workload, network, secret and audit controls with explicit trust boundaries, verification evidence and managed-service limitations.
Kubernetes security depends on the permissions and paths available to people, workloads and automation. A namespace name or a security tool does not establish the boundary by itself. The review must show which actions are permitted, which are denied and how those outcomes are observed.
This guide is for the platform and security owners designing the controls. The companion production hardening checklist turns that design into targeted change and acceptance tests. Neither article certifies a cluster or substitutes for review of the actual environment.
Record the version and responsibility boundary
This guidance was reviewed against the linked official documentation in September 2026. Before implementation, record the target Kubernetes minor version, node operating system, runtime, CNI, storage driver, admission configuration and managed-service plan. Pin policy behavior to the version you have tested.
The examples use stable Kubernetes API groups and focus on Linux application namespaces. Windows workloads, host-level agents and specialized devices need separate controls. Do not copy a control-plane flag from a self-managed cluster into a managed service without checking who owns that configuration.
| Boundary | Evidence to collect | | --- | --- | | Human access | Identity provider, authentication controls, group mapping and emergency access | | Workload access | Service account, projected credentials and permitted API actions | | Platform access | Cloud identity, node access, control-plane configuration and provider responsibilities | | Data access | API permissions, database identities, storage encryption and key recovery | | Change authority | Who can alter bindings, admission policy, images and network rules |
Inspect effective configuration rather than declare the system universally secure or insecure by default. Defaults can differ across distributions and installations, and later grants can change their meaning.
Design authorization around actions and escalation paths
Separate routine observation, deployment and incident intervention. A developer who can read pod status does not necessarily need permission to execute commands inside a production container. A deployment identity needs the resources and namespaces it manages, not automatically every cluster action.
RBAC good practices identify escalation risks beyond an obvious cluster-admin binding. Review who can create workloads, use service accounts, bind roles, approve certificates or change admission controls. Those powers can expose data indirectly.
Use a Role or a namespaced RoleBinding where the access boundary is a namespace. A ClusterRole can be reused through a RoleBinding without making the grant cluster-wide; the binding scope matters. Review aggregated roles and other authorizers as well as individual YAML files.
Test both expected access and expected denial using representative identities. An authorization check is useful evidence for a particular API action, but it does not prove that a workload cannot obtain equivalent access through another path.
Keep emergency access accountable and time-bounded. Record who approved it, how it was used and how the grant is removed. A permanently privileged “break glass” account used for everyday work is a different operating model.
Use admission controls with a versioned exception process
The Pod Security Standards define Privileged, Baseline and Restricted profiles. Pod Security Admission can enforce, warn or audit against a selected profile and version. The standards and the admission mechanism are related but not interchangeable concepts.
Inspect the namespace labels and cluster-level exemptions. A workload that passes in a namespace exempt from enforcement has not demonstrated compliance with the intended policy.
Use warning and audit evidence to identify incompatibilities before changing enforcement on a live namespace. Check application containers, init containers and approved debugging paths. A rejected replacement pod can leave an existing workload running until its next restart, making a policy rollout look safer than it is.
Read-only root filesystems are an additional hardening choice, not a blanket requirement of the Restricted profile. Test writable paths, temporary data and diagnostics explicitly. System agents that need exceptional host access should have narrow placement and ownership rather than an undocumented exemption covering unrelated applications.
Verify network controls at the traffic path
A NetworkPolicy object requires a network implementation that enforces it. The Kubernetes network-policy documentation also describes additive policy behavior: allowed traffic can come from the union of applicable policies.
Inventory required flows before isolating a namespace. Include DNS, application dependencies, identity services, telemetry and control-plane access where required. NetworkPolicy is not a complete layer-7 authorization or encryption system.
Use a connection test matrix that includes a permitted caller, a denied caller and the actual destination. Record namespace and pod labels, ports, protocol and the plugin version. Test after policy propagation and after rescheduling. A connectivity test made before the plugin applies a new object can give the wrong impression.
Do not treat a failed DNS lookup as proof that a direct destination connection is blocked. Conversely, permitting DNS is not permission to reach every address returned. Handle external egress and node-local paths according to the implementation's documented semantics.
Follow a secret through every copy
Access to a Kubernetes Secret depends on authorization; possession of API connectivity alone is not permission to read it. However, permissions to create or alter workloads can provide indirect access to credentials mounted in those workloads. The official Secret security guidance explains these exposure paths.
Map the value from its source to the application:
| Stage | Question to resolve | | --- | --- | | Source | Who can read, issue or rotate the credential? | | Synchronization | Does a controller copy it into a Kubernetes Secret? | | API storage | Which at-rest protection and key-management configuration covers that copy? | | Delivery | Which pod and container receive it, and through which mechanism? | | Use | Can logs, diagnostics, process access or application behavior expose it? | | Rotation | How does the running application begin using the replacement value? |
Base64 is an encoding, not encryption. At-rest encryption is a separate cluster setting. A synchronization operator does not automatically change etcd protection. Direct external delivery may avoid a Kubernetes Secret copy, depending on the integration, but still needs access controls and protection inside the workload.
Review the encryption-at-rest procedure with the platform owner. Enabling a configuration for future writes is not sufficient evidence that older data has been rewritten under it. Keep required decryption keys available through rotation and restore tests. Losing access to keys can become an availability incident.
For Kubernetes API credentials, prefer supported short-lived projected service-account tokens over manually distributed long-lived tokens. Verify the audience and consumer behavior. Workloads that do not call the Kubernetes API should not receive an unnecessary token.
Make the image policy answer a precise question
A vulnerability scan, a signature and a registry restriction establish different things. A scan identifies known findings under its database and configuration. A signature verifies an identity or key made an assertion about an artifact. Neither proves that the application is safe for every use.
Record the approved image digest, builder identity, provenance requirements and admission decision. Verify what happens when the verification service is unavailable. A fail-closed rule can stop a recovery rollout, so its emergency procedure must be designed in advance.
Use risk-based remediation and exception ownership rather than promising that a clean scan establishes compliance. Track which running workloads use an affected artifact when new information arrives. Rebuilding an image is only part of the response; deployed workloads must consume the approved replacement.
Keep audit collection useful without capturing secret bodies
Kubernetes audit policy uses the first matching rule. Resources belong to API groups: pods are in the core group, while deployments are in apps.
The following illustrative policy records metadata without request or response bodies. It is a starting point for testing, not a complete compliance configuration or a policy to apply blindly:
~~~yaml apiVersion: audit.k8s.io/v1 kind: Policy omitStages:
- RequestReceived
- level: Metadata
- group: ""
- secrets
- configmaps
- pods
- pods/exec
- group: apps
- deployments
- level: Metadata
rules:
resources:
resources:
resources:
~~~
The catch-all keeps other events at metadata level too. If you later add richer logging, place sensitive-resource rules before broader matches and inspect the resulting event contents. Request or response bodies can expose credentials in Secrets, ConfigMaps, pod environment fields or custom resources.
Metadata itself can contain sensitive identities, resource names and request information. Protect the destination, retention, readers and export path. A policy file alone does not enable an audit backend, and a managed service may expose different logging controls.
In a test cluster, exercise a Deployment change, a Secret read and an exec request using test identities and non-sensitive fixtures. Confirm the resource groups, user, verb, decision and stages in the events. Check that bodies are absent and that collection failure is observable. Do not use live credential values to test whether logging leaks them.
Connect detection to a response owner
Runtime and API signals need a triage path. Define which unexpected process, access attempt or network behavior deserves investigation and who can contain the affected workload.
A useful exercise starts with a test alert and ends with a responder locating the workload, preserving evidence, restricting the relevant access and identifying the safe recovery path. Avoid destructive containment that removes the only evidence before security has assessed it.
Validate sensor coverage across node types and operating systems. Installing a detector on one node group does not demonstrate visibility into serverless or differently configured workloads.
Next action: maintain an evidence register
For each control, retain its scope, version, owner, test result, date and exception. Distinguish a configuration check from a behavior test and a periodic assessment from continuous operation.
Compliance frameworks also require organizational scope, processes and evidence outside Kubernetes. This article does not map a few settings to SOC 2, PCI DSS or another attestation. Have the relevant reviewers assess the full obligation.
Use Ampity's cloud security and compliance service to discuss a scoped control review or implementation. Agree ongoing monitoring, incident duties and coverage separately; they are not implied by this guide.