Container and Kubernetes Security: Docker, K8s and Best Practices

Quick answer: Containers and Kubernetes have become the standard way to run modern applications fast and at scale, but this speed often lets security slip through unnoticed. Container security is addressed in four layers. First, image security, scanning container images against known vulnerabilities and pulling them only from trusted sources. Second, runtime security, not running a container with root privilege, restricting unnecessary capabilities, and keeping the container isolated from the host. Third, Kubernetes cluster security, restricting access to the API server with strict authentication, limiting pod to pod traffic with network policies, and correctly configuring role based access control (RBAC). Fourth, secrets management, not leaving database passwords and API keys embedded in the container image or environment variables, protecting them with a secrets management tool. Without applying these four layers together, a container environment stays fast but vulnerable.

Containers package an application and all its dependencies into a single portable unit, and Kubernetes automatically deploys and manages these units at large scale. This architecture has dramatically increased development speed, but it has also created a new attack surface that traditional security models overlook. We covered the general security of source code and the software supply chain in source code security audit, SAST, DAST, SCA and supply chain attacks. This article addresses the security risks and defense specific to containers and Kubernetes.

Why containers need a different security approach

On a traditional server, security is protecting a relatively static target. In the container world, the environment constantly changes, hundreds of containers are created and destroyed within seconds, images are updated frequently, and an application is split into dozens of microservices. This dynamism turns security into a continuous and automated process rather than a one time check.

Also, containers share the host's kernel, unlike virtual machines they do not provide full isolation. This raises the risk of escaping from a container to the host or to other containers. This risk makes container security not just an extension of application security but a discipline of its own.

Image security, starting from the foundation

A container's security starts with the image it is based on. An insecure or outdated base image creates a weak foundation no matter how much security you add on top.

  • Vulnerability scanning. Every image must be automatically scanned against known vulnerabilities before deployment. Adding this to the build pipeline (CI/CD) prevents a risky image from slipping into production.
  • Minimal image usage. The fewer components an image has, the smaller the attack surface. Minimal images that contain only what is necessary should be preferred over large images with unnecessary tools and libraries.
  • Trusted source. Images should be pulled only from verified and trusted registries, with their signature and source verified. This is a basic defense against supply chain attacks.
  • Regular updates. Even if an image is secure once, new vulnerabilities emerge over time. Images must be regularly rescanned and updated.

Runtime security, while the container runs

Once a container starts running, a few basic rules narrow the attack surface.

  • Non root user. A container should run, whenever possible, not with root privilege but with a restricted user. If an attacker compromises the container, the damage stays far more limited without root privilege.
  • Least privilege and capability restriction. A container should be given only the Linux capabilities it needs, and access to unnecessary system calls should be restricted.
  • Read only file system. Where possible, the container's file system should be made read only, so an attacker cannot write a persistent change inside the container.
  • Resource limiting. Setting CPU and memory limits on a container matters for both performance and security, because an unlimited container, once compromised, can exhaust the entire host.
Layer Main risk Basic measure
Image Known vulnerability, malicious image Scanning, minimal image, trusted source
Runtime Container escape, privilege escalation Non root user, capability restriction
Kubernetes cluster API access, pod to pod spread RBAC, network policies, authentication
Secrets Embedded password and key Secrets management tool, never embed in image

Kubernetes cluster security

While Kubernetes manages containers at large scale, it carries a broad attack surface of its own. Cluster security is built across a few basic areas.

  • API server access. The Kubernetes API server is the cluster's control center. Access to it must be protected with strict authentication and authorization, and it must never be exposed to the open internet.
  • Role based access control (RBAC). Every user and service should be given only the narrowest privilege it needs. Overly broad privileges put the entire cluster at risk if an account is compromised.
  • Network policies. By default, all pods in a cluster can talk to each other. Network policies restrict which pod can talk to which, so even if a pod is compromised the attacker cannot spread across the whole cluster.
  • Namespace isolation. Keeping different teams' or applications' resources in separate namespaces both maintains order and limits accidental or malicious access.
  • Audit logs. All important operations in the cluster must be logged and monitored, so unusual access or a configuration change is noticed quickly.

Secrets management, the most common mistake

The most common mistake in the container world is embedding database passwords, API keys and certificates into the container image or a plaintext environment variable. Once an image is shared or pushed to a registry, the secret inside it is considered leaked. We covered the real impact and prevention of leaked secrets in detail in leaked API keys and secrets.

The right approach is to keep secrets entirely separate from code and image. Kubernetes offers its own secrets mechanism, but for a stronger setup a dedicated secrets management tool, limiting access by authorization, and regularly renewing secrets (rotation) are needed.

Container and Kubernetes security checklist

Before putting a container environment into production, verify these items.

  • Are all images automatically scanned for vulnerabilities before deployment?
  • Are images pulled only from trusted and verified sources?
  • Do containers run with a non root user?
  • Is the Kubernetes API server protected with strict authentication and closed to the open internet?
  • Is RBAC correctly configured, giving every user and service least privilege?
  • Do network policies restrict unnecessary pod to pod traffic?
  • Are secrets kept in a dedicated secrets management tool rather than embedded in the container image or a plaintext environment variable?
  • Are cluster operations logged and regularly monitored?

A container environment that completes this list runs both fast and secure. At DSET we audit and harden container and Kubernetes infrastructures with this framework. We also covered the general framework of enterprise firewalls and network security in enterprise firewall selection, NGFW guide.

Container escape, the most serious threat

The most serious scenario in container security is container escape. An attacker uses a vulnerability in an application to break out of the container's isolation and gain direct access to the host. When this happens, the attacker is no longer limited to a single container, they can access every other container running on that host and the rest of the cluster.

The most common causes of container escape are these. Running the container with root privilege gives the attacker root privilege on the host too if an escape occurs. Defining unnecessary Linux capabilities gives the attacker the ability to perform kernel level operations. Containers running in privileged mode disable most of the isolation and provide almost direct host access. And an outdated container runtime stays vulnerable to known escape vulnerabilities.

The way to reduce this risk is to uncompromisingly apply the runtime hardening described in the previous section, a non root user, least privilege, avoiding privileged mode and keeping the runtime updated. In addition, a monitoring layer that detects anomalous behavior at the container runtime level can catch an escape attempt in real time.

Security in the CI/CD pipeline, shifting left

The most effective point to apply container security is the build pipeline (CI/CD) before a container goes to production. This is called shifting security left, preventing the problem at the very start of the development process instead of catching it in production.

In practice this means passing through a few automated gates. When an image is built it is automatically scanned for vulnerabilities, and if a critical vulnerability is found the build is stopped. Kubernetes configuration files (manifests) are scanned for misconfigurations before being applied to production, for example whether a pod is defined in privileged mode is checked automatically. And an image is pushed to the registry only once it passes the defined security threshold. These automated gates greatly prevent human error from slipping into production. We also covered the general framework of build pipeline security in supply chain attacks.

Security in a microservices architecture, an added layer

Kubernetes is often used together with a microservices architecture, where an application is split into dozens of small, independent services. This architecture provides flexibility but brings added complexity for security, because now it is not a single application that needs protecting but dozens of services constantly talking to each other.

Two principles stand out in this environment. Service to service authentication is a service proving who it is when connecting to another, so a compromised service cannot impersonate others. A service mesh encrypts and authenticates all traffic between services, which is a way to centrally manage secure communication among microservices. When set up correctly, even if one microservice is compromised, it becomes far harder for the attacker to spread to other services.

Frequently Asked Questions

Are containers less secure than virtual machines? Not by nature, but they carry a different threat model. Because containers share the host's kernel, isolation is weaker than virtual machines, so runtime hardening (non root user, capability restriction) is critically important.

How should a small team prioritize Kubernetes security? The three most critical steps are closing the API server to the open internet, applying least privilege with RBAC, and never embedding secrets in code or images. These are the steps that reduce the most risk for the least effort.

Is image scanning enough, is runtime monitoring needed? No, both are needed. Image scanning catches known vulnerabilities before deployment, but only runtime monitoring can catch anomalous behavior that occurs while a container is running (an unexpected network connection, a privilege escalation attempt).

Is keeping secrets in Kubernetes' own mechanism enough? It provides basic protection, but in production environments a dedicated secrets management tool offers additional layers such as stronger encryption, access control and automatic rotation. This additional layer is recommended for critical systems.

Sources

To audit your container and Kubernetes infrastructure for vulnerabilities, misconfiguration and secrets management, contact DSET.