Kubernetes Hardening: A Tested Change Checklist
Harden a Kubernetes application namespace with verified access, network, pod-security and secret-rotation checks, plus explicit exceptions and stop conditions.
Use this checklist when the security design is agreed and you need to make a production namespace safer without breaking the workload. It focuses on changes, verification and exceptions. For trust boundaries and audit architecture, read the companion Kubernetes security guide.
Start with a representative non-production environment and named application owner. Record the Kubernetes version, Linux or Windows node scope, CNI version and current policies. The examples below concern Linux application pods and stable RBAC APIs. They are not a complete policy bundle for every cluster.
Establish what is present before changing it
Do not infer effective permissions from the existence of a service account. With RBAC enabled, Kubernetes default service accounts have no permissions beyond the default discovery access unless additional grants are made. A cluster-admin binding is a risky grant, not the universal default.
Inspect workload identities, effective bindings, admission exemptions, credential delivery and permitted traffic. Record the approved deployment and emergency-access identities. Keep a tested way to recover if a policy prevents the next rollout.
For every proposed change, write the expected allowed behavior, expected denial and stop condition. A successful manifest apply is not the acceptance test.
1. Remove unnecessary access before adding new controls
Separate status inspection from logs, execution and deployment. Logs can themselves contain sensitive data. Executing a command inside a container can expose its credentials and permit actions using its network and workload identity.
In RBAC, exec is a pod subresource, not a verb. This illustrative Role permits the create action on that subresource within the payments namespace:
~~~yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: incident-exec namespace: payments rules:
- apiGroups:
- ""
- pods/exec
- create
resources:
verbs:
~~~
A Role alone grants no identity access; an appropriate binding is required. This example permits exec across pods in the namespace once bound, so it is a sensitive incident-access role, not a routine developer default. Consider narrower supported restrictions and keep the binding time-bounded through an approved access process.
Client protocols can use different API operations. Verify the actual exec client's request and add only the permissions it needs. Do not keep broadening the role merely to make the command work. Use the RBAC reference and audit evidence to distinguish a missing permission from a connection or application failure.
| Test | Pass condition | | --- | --- | | Routine observer | Can inspect approved status but cannot exec or read Secrets | | Deployment identity | Can change intended workload resources only in approved scope | | Incident identity | Can perform the approved intervention, with a recorded grant | | Unrelated namespace | The same identity is denied where no access was approved |
Test with the effective identity. If using impersonation for checks, the test operator needs explicitly authorized impersonation rights. Authorization tests do not replace checking indirect paths such as creating a pod that mounts a credential.
Disable automatic service-account token mounting for workloads that do not need Kubernetes API access, then verify startup and required integrations still work.
2. Prove network isolation and required connectivity
Before adding default-deny behavior, inventory the flows needed for startup, normal work and recovery. Include DNS, databases, identity endpoints, telemetry and required external APIs.
Confirm that the CNI enforces the relevant NetworkPolicy semantics. Policy objects are additive, so an existing broad allow can defeat the intended restriction. Account for plugin-specific behavior around node traffic and external addresses.
For a fictional payments namespace, use this test set:
| Connection | Intended result | | --- | --- | | Approved gateway to API port | Allowed | | Unrelated application to API port | Denied | | Worker to required database endpoint | Allowed | | Worker to an unrelated data service | Denied | | Application to its configured DNS service | Allowed for required DNS protocols | | Application to an unapproved external endpoint | Denied where egress policy is in scope |
Use test endpoints and authorized probes. Verify both source and destination policy effects. A DNS failure does not prove that a direct IP connection is denied.
Roll out to a controlled workload subset where the platform allows it, and watch connection errors and business completion. If required traffic fails, identify the missing flow and add a narrow, reviewed rule. Avoid leaving a blanket allow as the permanent fix.
3. Enforce the chosen pod-security profile
Compare the workload with the Pod Security Standards for the selected policy version. Inspect enforcement, warning and audit settings through Pod Security Admission.
A read-only root filesystem is additional hardening, not a requirement that defines Restricted PSS. Restricted includes controls such as non-root execution, privilege-escalation restrictions, capability restrictions and permitted seccomp settings, with operating-system and version conditions.
Test the application image and all relevant containers. A successful current pod does not prove its next replacement will pass admission. Run the proposed manifest through the target admission path in a safe environment, then create and restart the workload there.
If using a read-only root filesystem, identify each required writable location and provide a bounded volume where appropriate. Test temporary files, certificate handling and diagnostics. Do not switch the entire container back to privileged mode to solve a writable-directory error.
Record justified exceptions for host agents or specialized workloads separately. Specify who owns them, where they may run and what evidence permits continued use.
4. Choose secret delivery from consumption and rotation needs
Environment variables are not categorically safer than mounted files. The right mechanism depends on who can inspect it, whether the application can reload it, and what copies the integration creates.
| Delivery | Rotation and exposure check | | --- | --- | | Environment value | A running process does not receive a changed Secret value automatically; plan replacement and protect diagnostics | | Secret volume | Updates can reach the mounted files, but the application must reread them; subPath mounts do not receive automatic updates | | External integration | Verify whether it writes a Kubernetes Secret, how it authenticates and how the application receives refreshes | | Projected API token | Verify audience, expiry and that the consumer handles token renewal |
Check the Secret behavior documentation for the exact delivery path. Avoid exposing values in logs, command-line arguments, screenshots or test reports.
At-rest protection and API authorization remain necessary when an external controller syncs into a Kubernetes Secret. Direct external delivery still needs workload-level access controls. A “Vault enabled” or “external secrets enabled” checkbox does not establish either outcome.
Exercise rotation with a non-sensitive test credential. Issue the replacement, confirm the application uses it, revoke the old credential, and confirm old access fails without breaking required work. Preserve a recovery procedure that does not silently restore a compromised credential.
5. Verify the image and runtime decision paths
Record the exact image digest being admitted. Check the expected signer or builder identity if your policy requires verification, and confirm that a disallowed artifact is rejected. Use harmless test fixtures rather than a malicious image.
Scanning helps identify known vulnerabilities, but the pass criterion should reflect an agreed risk policy. A signed artifact can still contain a vulnerable application. A trusted registry can still contain an unapproved digest.
Test admission when the verifier is unavailable. Define the recovery procedure before choosing failure behavior. Otherwise an outage can force a hurried exception while the team is trying to replace a failed workload.
For runtime detection, trigger an approved, harmless test event and confirm that the right responder receives enough context to identify the workload. Record unsupported node types or workloads as coverage gaps. Do not claim complete detection from a successful agent installation.
6. Close the change with an evidence and exception record
Use one record per control change:
| Field | What to retain | | --- | --- | | Scope | Namespace, workload, version and affected identities | | Change | Previous and proposed policy, with a reviewed diff | | Verification | Allowed and denied tests, runtime results and relevant audit events | | Stop condition | The specific failure that pauses rollout | | Recovery | Authorized action to restore required service safely | | Exception | Risk owner, compensating measure and expiry or review date |
Do not close the work while an emergency binding or broad network exception remains unowned. Verify the intended denial again after removing temporary access.
Run the relevant checks after changes to CNI, admission, identity integration or application credential handling. A past result describes the configuration that was tested, not every future version.
For a scoped implementation review, bring this completed record to Ampity's cloud security and compliance service. Include the control gap and operational constraints, not production secret values. Monitoring and response coverage require a separate agreement.