Container and Kubernetes Security Policy Template: Baseline Rules for Images, Clusters and Workloads

Kubernetes clusters are usually built faster than anyone writes down which images may run, who may change the cluster and what a workload is allowed to do, so the defaults become the policy. And the defaults are permissive: the Kubernetes documentation states that Secret objects are stored unencrypted in etcd unless encryption is configured, and that pods accept all ingress and egress traffic until a NetworkPolicy selects them. This template gives [Organisation] a policy document covering trusted images, admission control, RBAC, secrets, network policy, runtime protection, logging and cluster lifecycle, mapped to ISO/IEC 27001:2022 and NIST CSF 2.0. It is written for platform engineering, cloud security and the CISO's office. For the threats behind each rule, see the Top 10 Kubernetes Security Risks.

How to use this template

• Replace the brackets. Text such as [Organisation], [Platform Team] and [30 days] is a placeholder for your names and values.
• "Must" is mandatory, "should" is recommended. A "should" may be departed from with a documented reason; a "must" needs an approved exception under section 12.
• Keep the policy tool-neutral. Put concrete settings (admission policies, CIS Benchmark profile versions, scanner thresholds) in a supporting Container Platform Standard that can change without re-approving the policy.
• Enforce as code. Most statements below can be enforced by admission control or pipeline gates. Record where each is enforced in the Standard, so audit evidence is a query, not a screenshot.
• Use it with the checklist. The Kubernetes Security Checklist is the operational check; this document is the approved policy it checks against.

1. Purpose

This policy sets the minimum security requirements for building, storing, deploying and running containers and for operating Kubernetes clusters at [Organisation]. It ensures that only trusted, scanned images run; that cluster and workload access follows least privilege; that secrets, network traffic and runtime behaviour are controlled; and that activity is logged and recoverable.

2. Scope

• All container images built by or for [Organisation], and all third-party images run in [Organisation] environments.
• All Kubernetes clusters, whether self-managed or managed services (for example Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift), in production, staging, development and test.
• Container registries, CI/CD pipelines that build or deploy images, Helm charts, operators and GitOps controllers.
• Human and non-human identities with access to clusters, registries or pipelines, including service accounts and CI/CD tokens.
• Standalone container hosts (Docker or containerd outside Kubernetes), which follow sections 5, 9 and 10.

3. Definitions

• Approved base image: a minimal image published by [Platform Team] in the approved registry and maintained under this policy.
• Admission control: checks the Kubernetes API server applies to requests before objects are stored, including Pod Security Admission and policy engines.
• Pod Security Standards (PSS): the Kubernetes profiles Privileged, Baseline and Restricted. Privileged is unrestricted; Baseline prevents known privilege escalations; Restricted follows current pod hardening practice.
• Image digest: the sha256 identifier unique to an image manifest, which, unlike a tag, cannot be moved to different content.
• Workload identity: the Kubernetes service account, or cloud identity bound to it, that a pod uses to call APIs.
• System namespace: namespaces holding cluster components, such as kube-system and those of the CNI, ingress and policy engine.

4. Roles and responsibilities

5. Image and supply chain security

1. Images must be built from approved base images. Base images should be minimal (distroless or slim) and must not contain shells, package managers or debugging tools unless a documented need exists.
2. Images must be built by the approved CI/CD pipeline. Images built on developer workstations must not be deployed to production.
3. Images must run as a non-root user, set by the USER instruction in the image and by runAsNonRoot in the workload.
4. Images must not contain secrets, credentials, private keys or tokens. Pipelines must scan image layers for secrets before push. See the Secrets in Container Images and Build Artefacts Guide.
5. Every image must be scanned for known vulnerabilities before push and continuously while deployed. Images with [critical] vulnerabilities that have a fix available must not be deployed to production; deployed images must be rebuilt within the timescales of the [Vulnerability Management Policy].
6. Production images must be signed by the pipeline, and clusters must verify signatures or provenance at admission. See the Sigstore Guide.
7. Production workloads must reference images by sha256 digest, or the admission policy must resolve and verify the digest, so a tag cannot be repointed to different content.
8. A software bill of materials (SBOM) should be generated for every production image and stored with it.
9. Production clusters must pull only from [approved registries]. Public registry images must be mirrored, scanned and approved before use. See the Container Registry Security Guide.

6. Cluster configuration and hardening

1. Clusters must be configured to the [CIS Kubernetes Benchmark or provider-specific CIS Benchmark] profile named in the Standard, with deviations recorded as exceptions.
2. The API server, kubelet and etcd must not be reachable from the internet. API server access must be restricted to [approved networks or private endpoints].
3. Anonymous access to the kubelet must be disabled and kubelet authorisation must use Webhook mode, not AlwaysAllow.
4. Encryption at rest must be configured for Secret objects, using a KMS provider where the platform supports it.
5. Clusters must run a Kubernetes minor version that receives upstream or provider security patches. Upgrades must be planned at least [two] months before end of support.
6. Access to the cloud instance metadata service from pods must be blocked or limited to what workload identity requires.
7. Node operating systems must be container-optimised or hardened images, patched within [14 days] for critical issues.

7. Admission control and workload security

1. Every namespace must carry a Pod Security Admission label. Application namespaces must enforce the Restricted profile; Baseline is permitted only with an exception; Privileged is limited to system namespaces listed in the Standard.
2. New or changed profiles should be introduced in warn and audit modes before enforce mode, so violations are visible before pods are rejected.
3. Workloads must not use privileged containers, hostPath volumes, hostNetwork, hostPID or hostIPC outside approved system namespaces.
4. Containers must set allowPrivilegeEscalation to false, drop ALL Linux capabilities (adding back only NET_BIND_SERVICE where needed) and use the RuntimeDefault seccomp profile or a stricter profile.
5. Containers must declare CPU and memory requests and memory limits. Namespaces must have a ResourceQuota and LimitRange.
6. A policy engine must enforce the rules in sections 5 and 7 that Pod Security Admission does not cover, including allowed registries, signature verification and required labels. See the Kubernetes Admission Control Guide.
7. Admission webhooks must be highly available and their failure policy documented, so an outage neither blocks recovery nor silently disables enforcement.

8. Access control and RBAC

1. Human access to clusters must use [Organisation] single sign-on with MFA. Static client certificates and long-lived tokens must not be issued to people.
2. Permissions should be granted with namespace-scoped RoleBindings rather than ClusterRoleBindings. Wildcard verbs or resources must not be used in roles granted to people or application service accounts.
3. cluster-admin must be held only by [named break-glass identities] and the [Platform Team] through just-in-time elevation. Users must not be added to the system:masters group.
4. Bindings to system:unauthenticated and system:anonymous must be reviewed and removed unless required.
5. The escalate, bind and impersonate verbs, create on pods in privileged namespaces, and get on nodes/proxy must be treated as privileged permissions and approved like cluster-admin. The Kubernetes documentation notes that get on nodes/proxy is not a read-only permission.
6. RBAC bindings must be reviewed at least [every six months] by namespace owners and evidence retained. See the Kubernetes RBAC Guide.

9. Secrets and workload identity

1. Secrets must not be stored in ConfigMaps, environment files committed to source control, Helm values in plain text or image layers.
2. Secrets should be held in [the approved secrets manager] and delivered through an external secrets operator or the Secrets Store CSI Driver.
3. Get, list and watch on Secret objects must be limited to the components and administrators that need them. Granting list on Secrets implicitly allows reading their contents, and anyone who can create a pod in a namespace can read the Secrets that pod mounts; both must be treated as secret access in reviews.
4. automountServiceAccountToken must be set to false for service accounts and pods that do not call the Kubernetes API.
5. Workloads must use bound, short-lived service account tokens. Legacy long-lived service account token Secrets must not be created. See the Kubernetes Service Account Token Guide.
6. Workloads that call cloud APIs must use the platform's workload identity federation rather than static cloud access keys stored in the cluster.
7. Each workload must use its own service account; the default service account must not be granted permissions.

10. Network security

1. Clusters must use a CNI plugin that enforces NetworkPolicy.
2. Every application namespace must have a default deny NetworkPolicy for ingress and egress, with explicit policies allowing required flows.
3. Egress to the internet must be limited to approved destinations or routed through [egress gateway or proxy].
4. Services of type LoadBalancer and NodePort, and Ingress objects exposed to the internet, must be approved by [Cloud Security Team]. The use of externalIPs should be blocked, for example with the DenyServiceExternalIPs admission controller.
5. Traffic between services that carries [Confidential] data should be encrypted in transit, using a service mesh with mutual TLS or an encrypting CNI. See the Service Mesh Security Guide.

11. Runtime protection, logging and monitoring

1. Kubernetes API server audit logging must be enabled with an audit policy that records at least Metadata level for all requests and Request level for changes to RBAC, Secrets, admission configuration and workloads. Audit logs must be protected from general access and forwarded to [SIEM].
2. Container runtime detection must run on production nodes and alert on shell execution in containers, writes to sensitive host paths, unexpected privilege changes and connections to the metadata service. See the Container Runtime Security Guide.
3. Detections must cover, as a minimum, MITRE ATT&CK T1609 Container Administration Command, T1610 Deploy Container, T1611 Escape to Host and T1613 Container and Resource Discovery. See the Kubernetes Audit Log Detection Guide.
4. Logs must be retained for [12 months], with [90 days] immediately searchable.
5. Cluster state (manifests, RBAC, policies) must be held in version control and recoverable, and etcd or cluster backups must be encrypted and tested at least [annually]. See the Kubernetes Backup and Recovery.
6. Suspected cluster compromise must be handled under the [Incident Response Policy] using the Kubernetes Cluster Compromise Playbook, with evidence preserved before nodes are replaced.

12. Exceptions

1. Exceptions must be requested through [exception process], stating the requirement, the workload, the reason, compensating controls and an expiry date no longer than [12 months].
2. Exceptions must be implemented as narrowly scoped admission policy exemptions (named namespace or workload), never by disabling a policy cluster-wide.
3. [Cloud Security Team] must report open and expired exceptions to [the security governance committee] each quarter.

13. Compliance and framework mapping

Compliance is measured continuously through admission policy reports, posture scanning against the CIS Benchmark and image scan results. Breaches of this policy are handled under [disciplinary or supplier procedure].

NIST SP 800-190, Application Container Security Guide, gives the underlying risk model (image, registry, orchestrator, container and host risks). See the NIST SP 800-190 Container Security Guide.

14. Review

This policy is reviewed at least annually by [CISO], and after any major Kubernetes platform change, significant incident or change to the CIS Benchmark profile in use. Version: [1.0]. Approved by: [name, role]. Date: [date].

Implementation guidance

1. Inventory first. List every cluster, registry and pipeline, including development clusters and managed services created by product teams. Unknown clusters are the usual gap.
2. Measure before enforcing. Apply Pod Security Admission labels in warn and audit modes and run policy engine rules in audit mode for [two to four weeks]. Use the reports to size the remediation work and the exception list.
3. Enforce in rings. Enforce on new namespaces first, then development, staging and production. Keep the previous policy version in source control so a bad rule can be rolled back with one revert.
4. Fix the identity basics early. Removing cluster-admin from people, disabling token automount and moving cloud keys to workload identity close the paths attackers use most. Exposed consoles and credentials inside pods were the root of the Tesla Kubernetes cryptojacking incident. See the Kubernetes NHI Security Guide.
5. Adapt to size. Small teams on a managed service can rely on provider defaults for control plane hardening and focus on sections 5, 7, 8 and 9. Large or regulated estates should add signature verification, SBOMs and mesh encryption as mandatory.
6. Track metrics: percentage of namespaces enforcing Restricted; images deployed by digest and signed; critical vulnerabilities in running images past due date; cluster-admin bindings held by people; namespaces with default deny; open exceptions past expiry.

Common failure patterns to avoid: enforcing Restricted on day one and then disabling admission control when deployments break; policy exemptions granted cluster-wide instead of per workload; treating list on Secrets as harmless; tags such as latest in production manifests; and development clusters left outside the policy while holding production credentials.

Related NHI Mgmt Group resources: Top 10 Kubernetes Security Risks · Kubernetes Security Guide · Container Security Guide · Kubernetes Secrets Security Guide · Cloud Security Policy Template