Container and Kubernetes Security Basics

Kubernetes container security means protecting systems where apps are packaged as containers and run in large numbers. A container bundles an app with what it needs and runs separately from other apps on the same machine. Kubernetes is software that manages containers in large groups, for example starting them, moving them and adding more automatically, and the whole group of machines it manages is called a cluster. This article explains the main risks according to NIST SP 800-190 and six basic steps.

How containers differ from virtual machines

Each VM (virtual machine) has its own operating system and is separated from the others by a hypervisor (software that divides hardware among virtual machines). Several containers, by contrast, share one kernel (the core of the operating system). NIST says containers are isolated well, but the boundary is not as clear as with a VM. If configuration is careless, containers can reach each other and the host (the machine that runs the containers) more easily than VMs can. NIST does not ask you to pick one or the other: an organization can use VMs to manage hardware and containers to package apps together.

The five main risk areas in NIST SP 800-190

NIST divides the risks by component of a container system into five areas:

• Image: the template used to create a container can contain vulnerabilities, configuration defects, malware or passwords embedded in clear text, and may come from an untrusted source
• Registry (the store of images): connections over insecure channels, stale images left behind, and access that is not restricted enough
• Orchestrator (the software that manages containers, such as Kubernetes): administrators with too much access, unauthorized access, poorly separated traffic between containers, and workloads of different sensitivity mixed together
• Container: vulnerabilities in the software that runs containers (the runtime), unrestricted network access, insecure runtime configuration, application vulnerabilities, and unapproved containers that someone started
• Host OS (the operating system of the host machine): a large attack surface, a shared kernel, vulnerable components, improper user rights, and tampering with the file system

The final NIST SP 800-190 was published in September 2017, more than 9 years ago, and the author found no revised edition, so it serves here as a frame for the risks. For current Kubernetes settings, use the official Kubernetes documentation in the steps below. NIST warns that traditional vulnerability tools often cannot detect vulnerabilities inside containers, which gives a false sense of safety, so it recommends tools designed for containers that connect to the image build process (see the DevSecOps article). NIST also recommends keeping passwords and keys outside images and having the orchestrator supply them at run time, and configuring images to run as a user without high privileges.

Six basic steps

The order below is this article's own proposal, put together from the cited documents. It is not an order that any one document sets:

• Use trusted images and scan them before use: use only images from sources you can verify, and scan for vulnerabilities before running them
• Set permissions with RBAC: RBAC (role-based access control, permissions by role) gives users and program accounts only the permissions they need
• Enforce Pod Security Standards: a Pod is the smallest unit Kubernetes runs, made of one or more containers. The standards set what a Pod may do, and are enforced one namespace at a time (a namespace splits a cluster into groups, for example by team or system)
• Limit communication with NetworkPolicy: a NetworkPolicy is a rule that sets who a Pod may talk to
• Protect Secrets: Secrets are Kubernetes objects that hold confidential values such as passwords and keys. Limit who can read them and turn on encryption at rest
• Turn on audit logging and review access regularly: an audit log records who did what to the cluster, and a regular review removes permissions that are no longer used

RBAC: grant only the permissions needed

RBAC sets what users and program accounts (service accounts) may do through the Kubernetes API (the API is the channel used to give the cluster commands). The Kubernetes RBAC good practices page recommends using a RoleBinding (grants rights within one namespace) rather than a ClusterRoleBinding (grants rights across the whole cluster) where possible, and avoiding wildcards (*), because they also cover resource types created later. Use cluster-admin (the highest privilege) only where needed, and keep users out of the system:masters group, because that group bypasses all permission checks and removing a binding does not take that access away.

Some permissions that look ordinary have the effect of high privileges. The get, list or watch permission on Secrets lets someone read the secret values. The permission to create Pods in a namespace gives indirect access to the Secrets and ConfigMaps in that namespace, and a Pod can run as any service account in it. The documentation therefore recommends turning off automatic mounting of service account tokens with automountServiceAccountToken: false for workloads that do not need to call the API. For program accounts, see the article on non-human identities and service accounts.

Pod Security Standards: limit what a Pod can do

Pod Security Standards define three policy levels, from loose to strict:

• Privileged: unrestricted, for trusted system workloads only. A Pod can bypass container isolation, for example by using the host's network
• Baseline: the least restrictive level that still blocks known privilege escalations. It forbids things such as privileged containers, hostNetwork, hostPID, hostIPC and hostPath volumes (a folder of the host machine attached into the Pod)
• Restricted: the strictest, following current best practice for hardening Pods, and it includes every Baseline requirement

Restricted adds requirements such as setting runAsNonRoot to true (do not run as root, the highest-privilege user on Linux), setting allowPrivilegeEscalation to false (a process may not gain extra privileges while running), dropping all capabilities (the smaller rights that make up root) and adding back only NET_BIND_SERVICE, and setting the seccomp profile (a filter on which kernel calls a container may make) to RuntimeDefault or Localhost.

Use Pod Security Admission (the checker built into Kubernetes) to enforce a policy per namespace through labels, which has three modes: enforce (reject a Pod that breaks the policy), audit (record it in the audit log but allow it) and warn (warn the user but allow it). The documentation says this feature has been stable since Kubernetes v1.25. Its example sets enforce at baseline while setting audit and warn at restricted, so you can see which Pods would fail if the policy were tightened, without blocking anything. This article sees that approach as a good fit for systems that are already running, and cautions against overly broad exemptions, because requests that match an exemption are skipped in every mode.

NetworkPolicy and Secrets

By default, every Pod in a cluster can talk to every other Pod. Once a NetworkPolicy selects a Pod, that Pod can send or receive only what the policy allows. The Kubernetes documentation recommends setting default-deny (refuse everything by default) in every namespace and then opening only the paths that are needed. A caution: a NetworkPolicy works only if the cluster's network layer (the CNI plugin) supports it, and if it does not, the policies you create have no effect. For network segmentation in general, see the article on network segmentation.

Secrets store values as base64, which is only a change of format and not encryption, and by default they sit in etcd (the cluster's database) unencrypted. Administrators must turn on encryption at rest themselves. You should also restrict the list and watch permissions on Secrets, keep Secret files that can be decoded out of the repository, and consider an external secret store, which the Kubernetes Secrets Store CSI Driver supports. This matches NIST's advice not to embed secrets in images.

Checking against CIS and the NSA/CISA guide

The CIS Kubernetes Benchmark (a set of Kubernetes configuration requirements produced by the Center for Internet Security) works as a checklist for whether a cluster is configured to good practice. The CIS web page says the PDF can be downloaded free for non-commercial use. When the author viewed it (October 2026), the page showed version 2.1.0 for general Kubernetes and separate versions for the EKS, AKS and GKE services, so pick the edition that matches what you run. The author did not open the document itself and so does not summarize its individual items.

The latest edition of the NSA and CISA Kubernetes Hardening Guide that the author found is version 1.2, dated August 2022 (version 1.0 came out in August 2021 and 1.1 in March 2022). It is more than 4 years old. The author could not open the PDF directly (the server refused automated downloads), so this summary rests on search results only, which say the guide recommends scanning containers and Pods for vulnerabilities, running containers with the least privilege, separating networks, using strong authentication, and auditing logs. Read the original and check whether a newer version exists before citing it, and rely on the current Kubernetes documentation for configuration details.

Common mistakes

• Running outside images without checking them: for example, grabbing a third party's image while troubleshooting. untrusted software can carry malware or known flaws (our view)
• Embedding passwords or keys in an image: anyone who can access the image can read the secrets
• Granting cluster-admin or broad rights for convenience: one compromised account then lets an attacker control the whole cluster
• Believing the base64 in Secrets is encryption: anyone who can read the file can decode the value
• Creating NetworkPolicies without checking that the network layer supports them: the policies have no effect and nobody notices

Start today

• List your clusters and namespaces: record the owner and importance of each one, including those used for testing
• Turn on the warn and audit modes of Pod Security Admission: set them at the restricted level on a namespace and see which Pods would fail, without blocking anything
• Check permissions: find who has cluster-admin or belongs to the system:masters group, and review bindings that grant rights to system:unauthenticated, which means anyone who can reach the API server
• Try a default-deny NetworkPolicy: test it in a test namespace first, and confirm that the CNI plugin supports it
• Check Secrets: find Secrets stored in a repository and turn on encryption at rest
• Download the CIS Benchmark edition that matches your cluster: then check against its items

To see where your organization's security stands overall, try the self-assessment. If you run many clusters or several clouds, see how a combined platform can help in the article CNAPP explained: how it differs from CSPM and CWPP.

Scope and accuracy

The information comes from NIST SP 800-190 (September 2017; the author read the PDF's summary, table of contents and the sections cited) and Kubernetes documentation pages read on 27 October 2026. Kubernetes documentation changes by version, so check the page for the version you run. The author did not read the content of the CIS Benchmark and did not open the NSA/CISA guide PDF. This article is an introduction, not a complete checklist; the Kubernetes documentation itself says its security checklist is not exhaustive.

References and further reading

• NIST SP 800-190: Application Container Security Guide: the five risk areas and countermeasures for container systems
• CIS Kubernetes Benchmark: Kubernetes configuration requirements and editions for cloud provider services
• Kubernetes: Pod Security Standards: the Privileged, Baseline and Restricted policies with their requirement lists
• Kubernetes: Pod Security Admission: the enforce, audit and warn modes and namespace labels
• Kubernetes: RBAC good practices: least privilege practices and privilege escalation risks
• Kubernetes: Good practices for Secrets: encryption at rest, access limits and external secret stores
• Kubernetes: Network Policies: Pod isolation, the default behavior and the network layer requirement
• Kubernetes: Security checklist: a baseline checklist for access, network and Pod security
• NSA/CISA Kubernetes Hardening Guide v1.2 (PDF): the NSA and CISA Kubernetes guide, August 2022 edition (may open only in a web browser)