Container and Kubernetes Security: What to Test Before You Deploy

Containers were supposed to make everything simpler. Package your application, ship it anywhere, run it the same way every time. And they did make deployment simpler. They also introduced an entirely new class of security problems that most teams are not testing for. Misconfigured containers and overprivileged Kubernetes pods have become the cloud-native equivalent of open S3 buckets: ubiquitous, dangerous, and almost always the result of defaults that prioritize convenience over security.

The shift from virtual machines to containers changed the attack surface fundamentally. Instead of a handful of long-lived servers with well-understood configurations, you now have hundreds or thousands of ephemeral containers running images built from layers you may not fully control, orchestrated by a system (Kubernetes) that has its own complex permission model, network architecture, and secrets management. Each layer introduces security decisions. Most teams are making those decisions implicitly by accepting defaults rather than explicitly by hardening their configurations.

This article covers the security issues we find most frequently in container and Kubernetes assessments, why they matter, and how to fix them before an attacker or an auditor finds them first.

The container security landscape

Container security is not a single problem. It is a stack of problems that spans the entire lifecycle from image creation to runtime orchestration. Understanding where security decisions live in that stack is the first step toward testing them effectively.

At the base layer, you have container runtimes: Docker, containerd, CRI-O, and others. These are the engines that actually run your containers, and they interact directly with the host kernel. A vulnerability or misconfiguration at this level can allow a container to escape its isolation boundary and access the host system.

Above the runtime sits the orchestration layer. For most organizations, this is Kubernetes, whether self-managed or through a managed service like Amazon EKS, Google GKE, or Azure AKS. Other teams use Amazon ECS, Docker Swarm, or HashiCorp Nomad. The orchestrator controls scheduling, networking, scaling, and access control. Its configuration determines who can deploy what, which pods can communicate with each other, and how secrets are distributed to running workloads.

Then there is the image supply chain: the base images you pull from public registries, the dependencies you install during the build process, the Dockerfiles that define how images are constructed, and the CI/CD pipelines that build and push those images to your private registry. A compromised or vulnerable image that makes it into your registry can propagate across your entire infrastructure within minutes.

Finally, there is runtime behavior: what your containers actually do when they are running. Even a well-built, minimal image can be exploited if the application inside it has vulnerabilities, if the pod has excessive permissions, or if network policies allow it to reach services it should not be able to access.

Container image security: what you build on matters

The security of your container starts with the image, and the image starts with the base. The choice of base image is one of the most consequential security decisions in the entire container lifecycle, yet it is often made casually. An engineer picks ubuntu:latest or node:18 because it works, and that image becomes the foundation for everything the organization deploys.

Base image selection

General-purpose base images like ubuntu, debian, or centos include hundreds of packages that your application does not need: shells, package managers, networking utilities, text editors, and system libraries. Every one of those packages is potential attack surface. If a vulnerability is discovered in any of them, your image is vulnerable even if your application code is perfectly secure.

Minimal base images dramatically reduce this surface. Alpine Linux images are typically 5-10 MB compared to 70-200 MB for Debian or Ubuntu bases. Distroless images from Google go further by removing everything except the application runtime: no shell, no package manager, no utilities. If an attacker compromises the application, there is nothing in the container to help them escalate or pivot. They cannot run curl to download tools because curl does not exist. They cannot spawn a shell because there is no shell.

Scratch images are the most minimal option: an empty filesystem. These are ideal for statically compiled applications like Go binaries that have no external dependencies. The resulting image contains only your application binary and nothing else.

Vulnerability scanning

Every image in your registry should be scanned for known vulnerabilities before it reaches production. This is non-negotiable. The tooling is mature and widely available: Trivy, Grype, Snyk Container, AWS ECR scanning, GCP Artifact Registry scanning, and Azure Defender for container registries all provide this capability.

The challenge is not scanning. It is acting on the results. A typical scan of a general-purpose base image will return dozens or hundreds of CVEs, most of which are in packages your application does not use. Teams quickly develop scan fatigue and start ignoring results entirely. The solution is to combine minimal base images (which have far fewer CVEs to begin with) with a policy that blocks deployment of images with critical or high-severity vulnerabilities in packages that are actually reachable by the application.

Scanning should happen at multiple points: in the CI/CD pipeline when the image is built, in the registry as a gating check before the image can be pulled, and continuously in the registry to catch newly disclosed vulnerabilities in images that are already deployed. An image that was clean when you built it last month may have critical CVEs today because new vulnerabilities are disclosed constantly.

Dockerfile best practices: building secure images

The Dockerfile is the blueprint for your container image, and it is where many security problems are introduced. We review Dockerfiles in nearly every container security assessment, and the same anti-patterns appear with striking regularity.

Running as root

By default, processes inside a Docker container run as root. This is the single most common Dockerfile security issue we find. If the application is compromised, the attacker has root access inside the container. While container isolation should prevent root inside the container from being root on the host, the reality is more nuanced. Kernel vulnerabilities, misconfigurations, and mounted volumes can all turn container root into host root.

The fix is straightforward. Create a non-root user in your Dockerfile and switch to it before the entrypoint:

• Add a RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser instruction
• Set file ownership with COPY --chown=appuser:appgroup when copying application files
• Switch to the non-root user with USER appuser before the CMD or ENTRYPOINT instruction
• Verify by running docker run --rm your-image whoami and confirming it does not return "root"

Multi-stage builds

A common anti-pattern is building the application inside the same image that runs it. The build stage requires compilers, build tools, development libraries, and source code. None of these should exist in the production image. They add attack surface, they increase image size, and they may contain sensitive information like internal package repository credentials.

Multi-stage builds solve this cleanly. The first stage uses a full build environment to compile the application. The second stage starts from a minimal base image and copies only the compiled artifact. The build tools, source code, and intermediate files are discarded. The production image contains only what is needed to run the application.

Secrets in image layers

Docker images are built in layers, and every layer is persistent. If you copy a secrets file into the image and then delete it in a later layer, the secret is still present in the earlier layer. Anyone who pulls the image can extract it by inspecting the layer history. We find this regularly: API keys, database credentials, SSH private keys, and TLS certificates baked into image layers.

Secrets should never appear in a Dockerfile. Not as COPY instructions, not as ENV variables, not as build arguments passed with --build-arg. Instead, use Docker BuildKit's --mount=type=secret feature for build-time secrets, and inject runtime secrets through Kubernetes Secrets, a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager), or environment variables provided by the orchestrator at deployment time.

Pinning versions

Using FROM node:latest or FROM python:3 means your image build is not reproducible. The same Dockerfile built today and next month will produce different images with different packages and potentially different vulnerabilities. Pin your base image to a specific digest or version tag: FROM node:20.11.0-alpine3.19 rather than FROM node:latest. Pin package versions in RUN instructions as well. Reproducible builds are a prerequisite for meaningful vulnerability management.

Kubernetes misconfigurations we find in every assessment

Kubernetes is a powerful orchestration platform with a security model that is both flexible and complex. That flexibility means there are many ways to configure it securely and even more ways to configure it insecurely. The following are the misconfigurations we encounter most frequently in security assessments.

Privileged pods

A privileged pod runs with all Linux capabilities and has direct access to the host's devices. It effectively has root access to the underlying node. Privileged mode is sometimes used for infrastructure components like CNI plugins or storage drivers, but we regularly find application pods running in privileged mode because a developer needed access to a specific device or capability during troubleshooting and the setting was never reverted.

A privileged pod is a complete break of container isolation. An attacker who compromises the application in a privileged pod has unrestricted access to the host node, and from there, to every other container on that node and potentially to the Kubernetes control plane.

The fix: use Pod Security Admission (or the deprecated PodSecurityPolicy) to enforce that no pods run in privileged mode. If a specific pod genuinely needs elevated privileges, grant the specific Linux capabilities it requires using securityContext.capabilities.add rather than enabling full privileged mode.

hostPath volume mounts

A hostPath volume mounts a directory from the host node's filesystem into the pod. This is dangerous because it allows the container to read and write files on the host. We have seen pods with hostPath mounts to / (the entire host filesystem), /var/run/docker.sock (the Docker socket, which grants full control over the container runtime), and /etc (which contains system configuration including credentials).

Mounting the Docker socket is particularly dangerous. With access to the Docker socket, an attacker can create new privileged containers, access the host filesystem, read secrets from other containers, and effectively control the entire node. This is one of the most straightforward container escape paths.

Default service accounts

Every Kubernetes namespace has a default service account that is automatically mounted into every pod unless explicitly disabled. In many clusters, this service account has permissions to query the Kubernetes API, list pods, read secrets, and sometimes even create or modify resources. If an attacker compromises a pod, the mounted service account token gives them authenticated access to the Kubernetes API.

The fix is twofold: set automountServiceAccountToken: false on pods that do not need API access (most application pods do not), and create dedicated service accounts with minimal RBAC permissions for pods that do need API access.

Exposed dashboards and management interfaces

The Kubernetes Dashboard, if deployed without proper authentication, provides a web-based interface for managing the entire cluster. We regularly find dashboards exposed to the internet or accessible to any authenticated user in the cluster, sometimes with cluster-admin privileges. The 2018 Tesla cryptojacking incident was enabled by an unauthenticated Kubernetes dashboard. Years later, we still find this same misconfiguration in production clusters.

Other management interfaces we find exposed include Prometheus, Grafana, Jaeger, Kibana, and etcd. Each of these can leak sensitive information about the cluster's internal state, running workloads, and sometimes credentials or secrets.

RBAC misconfigurations and over-permissioned service accounts

Kubernetes Role-Based Access Control (RBAC) is the primary mechanism for controlling who can do what in a cluster. It is also one of the most frequently misconfigured components. The RBAC model uses Roles (namespace-scoped) and ClusterRoles (cluster-scoped) to define permissions, and RoleBindings and ClusterRoleBindings to assign those permissions to users, groups, or service accounts.

The most dangerous RBAC misconfiguration is granting cluster-admin to service accounts that do not need it. The cluster-admin ClusterRole has unrestricted access to every resource in every namespace. A single compromised pod with a cluster-admin service account gives an attacker full control over the entire cluster: they can read all secrets, deploy new workloads, modify existing deployments, and access every namespace.

Other common RBAC issues we find include:

• Wildcard permissions: Roles with verbs: ["*"] or resources: ["*"] that grant access to every action on every resource type. These are the Kubernetes equivalent of IAM Action: "*" in cloud IAM policies.
• Secrets access granted too broadly: Service accounts with get or list permissions on Secrets resources. A service account that can list secrets in a namespace can read every secret in that namespace, including database credentials, API keys, and TLS certificates.
• Pod creation with escalation paths: Service accounts that can create pods can potentially escalate privileges by creating a pod with a more-privileged service account, mounting host paths, or running in privileged mode. Pod creation should be tightly controlled and combined with admission control policies.
• Bind and escalate verbs: Service accounts with the bind or escalate verbs on Roles or ClusterRoles can grant themselves or others additional permissions, effectively bypassing RBAC entirely.
• No audit of existing bindings: RBAC configurations accumulate over time. Roles and bindings created for specific tasks (debugging a production issue, running a one-time migration) are never cleaned up. Over months and years, the RBAC configuration drifts toward overly permissive, and nobody knows which bindings are still necessary.

Auditing RBAC requires tools like kubectl auth can-i --list, rbac-lookup, or rakkess to enumerate effective permissions for each service account and user. The goal is least privilege: every service account should have only the specific permissions it needs, scoped to the specific namespace it operates in. ClusterRoleBindings should be reserved for cluster-wide infrastructure components, not application workloads.

Network policies: controlling pod-to-pod traffic

By default, Kubernetes allows every pod to communicate with every other pod in the cluster, regardless of namespace. There is no network segmentation. A compromised pod in the frontend namespace can directly reach the database pods in the backend namespace, the monitoring stack in the monitoring namespace, and any other workload in the cluster. This default behavior is one of the most significant security gaps in Kubernetes and one of the most overlooked.

NetworkPolicies are the Kubernetes-native mechanism for controlling pod-to-pod traffic. They define ingress and egress rules based on pod labels, namespace selectors, and IP blocks. However, NetworkPolicies are only enforced if the cluster's CNI plugin supports them. Flannel, one of the most commonly used CNI plugins, does not enforce NetworkPolicies. Calico, Cilium, and Weave Net do.

The minimum viable network segmentation for a Kubernetes cluster includes:

• Default deny all: A NetworkPolicy in every namespace that denies all ingress and egress traffic by default. This is the baseline. Without it, any new pod deployed to the namespace can communicate with anything.
• Explicit allow rules: NetworkPolicies that allow specific traffic flows based on application requirements. The frontend pods can reach the API pods. The API pods can reach the database. Nothing else can reach the database directly.
• Egress restrictions: Pods should only be able to reach the external services they need. A backend API pod should not be able to make arbitrary outbound connections to the internet. Egress rules should allow DNS resolution (port 53) and specific external endpoints, and deny everything else.
• Namespace isolation: Workloads in different namespaces should not be able to communicate unless explicitly allowed. The development namespace should not have network access to the production namespace.

In managed Kubernetes services, network policy enforcement may require additional configuration. In EKS, you need to use the Calico or Cilium CNI add-on. In GKE, network policies must be explicitly enabled on the cluster. In AKS, Azure CNI with Calico network policies must be configured. The managed Kubernetes defaults do not include network policy enforcement in most cases.

Secrets management in Kubernetes

Kubernetes Secrets are the built-in mechanism for providing sensitive data (passwords, tokens, certificates) to pods. They are also one of the most misunderstood security features in Kubernetes. By default, Kubernetes Secrets are stored in etcd as base64-encoded values. Base64 is an encoding, not encryption. Anyone with access to etcd or with get permissions on Secrets resources can read them in plaintext.

The security issues with Kubernetes Secrets management fall into several categories:

Secrets stored unencrypted in etcd

If etcd encryption at rest is not configured, every secret in the cluster is stored as a base64-encoded string that anyone with direct etcd access can decode. In self-managed clusters, etcd encryption must be explicitly configured using an EncryptionConfiguration with a KMS provider or local encryption key. Managed services handle this differently: GKE encrypts etcd by default with Google-managed keys, EKS encrypts etcd by default, and AKS encrypts at rest but requires envelope encryption with Azure Key Vault for customer-managed keys.

Secrets in manifests and version control

Kubernetes Secrets are typically defined in YAML manifests. If those manifests are committed to version control, the secrets are now in your Git history permanently. Even if the manifest is later deleted, the secret can be recovered from the Git history. We find secrets in Git repositories in the majority of assessments. The solution is to use sealed-secrets, SOPS (Secrets OPerationS), or an external secrets operator that references secrets stored in an external vault rather than embedding them in manifests.

Overly broad access to secrets

If RBAC grants a service account get or list permissions on Secrets in a namespace, that service account can read every secret in the namespace. This is often more access than intended. A pod that needs access to a single database password should not be able to read TLS certificates, API keys, and every other secret in the namespace. Scoping secrets access by name using resourceNames in RBAC rules limits access to specific secrets.

External secrets management

The most secure approach to Kubernetes secrets is to store them outside of Kubernetes entirely and inject them at runtime. HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault all integrate with Kubernetes through CSI drivers, mutating webhooks, or operator patterns. These external systems provide access auditing, automatic rotation, dynamic secrets, and centralized management that Kubernetes Secrets alone do not offer. If your organization is running production workloads on Kubernetes, an external secrets manager should be part of your architecture.

Container escape techniques and how to prevent them

Container isolation relies on Linux kernel features: namespaces for isolation, cgroups for resource limits, and capabilities for privilege restriction. Container escapes exploit weaknesses in these boundaries to gain access to the host system. Understanding these techniques is essential for testing whether your defenses are effective.

Privileged container escape

This is the simplest and most common escape path. A container running in privileged mode has all Linux capabilities and direct device access. An attacker can mount the host filesystem, access the host's PID namespace, load kernel modules, or write to the host's cgroup filesystem to execute commands on the host. The prevention is straightforward: never run pods in privileged mode for application workloads. Use Pod Security Admission to enforce this.

Docker socket escape

If the Docker socket (/var/run/docker.sock) is mounted into a container, the container can issue commands to the Docker daemon on the host. This allows creating new privileged containers, mounting the host filesystem, or accessing other containers' environments. Monitoring and CI/CD tools sometimes mount the Docker socket for "Docker-in-Docker" functionality. This should be replaced with rootless alternatives or Kaniko for container image builds within Kubernetes.

Kernel exploits

Containers share the host kernel. A kernel vulnerability that allows privilege escalation from within a container can break container isolation entirely. CVE-2022-0185 (heap overflow in filesystem context), CVE-2022-0847 (Dirty Pipe), and CVE-2024-1086 (nf_tables use-after-free) are recent examples of kernel vulnerabilities that could be exploited from within containers. Prevention requires keeping host kernels patched, using container-optimized operating systems (Bottlerocket, Flatcar, Talos) that have minimal attack surface, and deploying seccomp profiles and AppArmor/SELinux policies that restrict the syscalls containers can make.

Metadata service access

In cloud environments, the instance metadata service (IMDS) at 169.254.169.254 is accessible from within containers by default. An attacker who achieves SSRF or code execution in a pod can query the metadata service to obtain the node's IAM role credentials, which typically have permissions to interact with cloud services like ECR, S3, and EC2. This was a key technique in several high-profile breaches.

Prevention: use IMDSv2 (which requires a session token) on AWS, enable Workload Identity on GKE, use Pod Identity on EKS, or use Azure AD Workload Identity on AKS. These mechanisms provide pod-level cloud credentials without exposing node-level credentials through the metadata service. Network policies that block egress to 169.254.169.254 provide an additional layer of defense.

Preventing escapes: defense in depth

No single control prevents all container escapes. Effective prevention requires layering multiple defenses:

• Pod Security Admission: Enforce the restricted profile, which blocks privileged pods, host namespaces, and most dangerous configurations.
• Seccomp profiles: Restrict the system calls a container can make. The default Docker seccomp profile blocks over 40 dangerous syscalls. Custom profiles can restrict further.
• AppArmor or SELinux: Mandatory Access Control that limits what files and operations a process can access, even if it has root inside the container.
• Read-only root filesystem: Set readOnlyRootFilesystem: true in the pod's security context. If the application needs to write to specific directories, mount writable emptyDir volumes for those paths only.
• Drop all capabilities: Set capabilities.drop: ["ALL"] and add back only the specific capabilities the application needs, if any.
• Container-optimized host OS: Use Bottlerocket, Flatcar, Google Container-Optimized OS, or Talos Linux. These operating systems have minimal packages, immutable filesystems, and are specifically designed for running containers securely.

Supply chain security for container images

Your container images are composed of layers, and those layers contain software you did not write. A typical Node.js application image includes a base operating system, system libraries, the Node.js runtime, and hundreds of npm packages. You control the application code. Everything else comes from the supply chain, and compromises in that supply chain are increasingly common.

The CI/CD pipeline is a critical link in this chain. If an attacker can modify the Dockerfile, inject a malicious dependency, or tamper with the built image before it reaches the registry, every deployment that uses that image is compromised.

Image signing and verification

Image signing provides a cryptographic guarantee that an image was built by a trusted party and has not been modified since it was signed. Cosign (from the Sigstore project) is the most widely adopted tool for container image signing. It integrates with OCI registries and can be verified at deployment time using admission controllers.

The signing workflow is: build the image, scan it for vulnerabilities, and if it passes, sign it with a key managed by your CI/CD system. At deployment time, an admission controller verifies the signature and rejects unsigned or tampered images. This prevents both external attackers (who cannot sign images with your key) and internal mistakes (deploying a development image that was never scanned).

Admission controllers

Kubernetes admission controllers intercept API requests before resources are persisted to etcd. They are the enforcement point for security policies in the cluster. Key admission controllers for container security include:

• Image policy enforcement: OPA Gatekeeper, Kyverno, or the built-in ImagePolicyWebhook can enforce that only images from approved registries are deployed, that images must be signed, and that images with critical vulnerabilities are blocked.
• Pod Security Admission: The built-in replacement for PodSecurityPolicy that enforces pod security standards (Privileged, Baseline, Restricted) at the namespace level.
• Resource quotas and limits: Enforce that every pod specifies CPU and memory limits, preventing resource exhaustion attacks and noisy-neighbor problems.
• Network policy requirements: Enforce that no pod can be deployed without an associated NetworkPolicy, preventing gaps in network segmentation.

Software Bill of Materials (SBOM)

An SBOM is a complete inventory of every component in your container image: operating system packages, language-specific dependencies, and their versions. Generating SBOMs for your images (using tools like Syft) and storing them alongside the image in your registry enables rapid response when new vulnerabilities are disclosed. Instead of scanning every image when a new CVE is announced, you can query SBOMs to identify which images contain the affected component within seconds.

Runtime security: detecting threats in running containers

Static analysis and hardened configurations prevent many attacks, but they cannot catch everything. Runtime security monitoring detects anomalous behavior in running containers: unexpected process execution, unusual network connections, filesystem modifications in read-only locations, privilege escalation attempts, and access to sensitive files.

Falco

Falco is the de facto open-source standard for container runtime security. It monitors system calls from containers and alerts on suspicious activity based on a rules engine. Default rules detect common attack patterns: a shell spawned in a container, a process reading /etc/shadow, an outbound connection to a cryptocurrency mining pool, or a binary executed from /tmp. Custom rules can be written for your specific application's expected behavior.

Sysdig and commercial alternatives

Sysdig Secure, Aqua Security, Prisma Cloud (Palo Alto), and other commercial platforms build on the same kernel-level monitoring (often using eBPF) but add features like automated response (killing a compromised container), compliance dashboards, forensic capture, and integration with SIEM/SOAR platforms. For organizations with mature security operations, these platforms provide the response automation that open-source tools lack.

Container sandboxing

For workloads that process untrusted input or run untrusted code, standard container isolation may not be sufficient. Container sandboxing technologies provide an additional isolation layer:

• gVisor: Implements a user-space kernel that intercepts system calls from the container, providing an additional boundary between the container and the host kernel. Used by GKE Sandbox.
• Kata Containers: Runs each container (or pod) in a lightweight virtual machine, combining the speed of containers with the isolation of VMs. The container gets its own kernel, so kernel vulnerabilities in the container cannot affect the host.
• Firecracker: The microVM technology behind AWS Fargate and Lambda. Creates lightweight VMs with minimal overhead for workload isolation.

These sandboxing technologies add latency and overhead, so they are typically used for specific high-risk workloads rather than across the entire cluster. However, for multi-tenant clusters or workloads that process untrusted data, the additional isolation is essential.

Kubernetes-specific attack paths

Beyond container escapes, Kubernetes introduces its own unique attack paths that exploit the orchestrator's architecture and trust relationships.

SSRF to the metadata service

If an application running in a pod is vulnerable to Server-Side Request Forgery (SSRF), an attacker can use it to reach the cloud metadata service at 169.254.169.254. In AWS, this returns the temporary IAM credentials of the EC2 instance (or EKS node) running the pod. These credentials often have permissions to access S3, ECR, or other cloud services, providing the attacker with a pivot point from application-level access to cloud infrastructure access.

This was a critical component in several major breaches. The defense includes enabling IMDSv2 with hop limit of 1 (which prevents containers from reaching the metadata service because the extra network hop exceeds the limit), using Workload Identity / Pod Identity to provide pod-specific credentials, and deploying network policies that block egress to 169.254.169.254.

Kubelet exploitation

The kubelet runs on every node and manages pod lifecycle. If the kubelet's API is exposed without authentication (which is the default configuration on some older clusters), an attacker who can reach a node's kubelet port (10250) can execute commands in any pod on that node, read pod logs, and access environment variables and mounted secrets.

In managed Kubernetes services, the kubelet is typically configured with authentication enabled by default. In self-managed clusters, verify that --anonymous-auth=false is set and that kubelet authentication uses client certificates or webhook authentication.

etcd access

etcd is the datastore that holds all Kubernetes state, including Secrets. If an attacker gains direct access to etcd (through a misconfigured firewall rule, a compromised node, or an exposed etcd port), they can read every secret in the cluster, modify RBAC policies, and alter workload configurations. etcd must never be exposed outside the control plane, should require mutual TLS for all connections, and should have encryption at rest enabled.

Service account token theft

When a service account token is mounted into a pod (the default behavior), an attacker who compromises the pod can use that token to authenticate to the Kubernetes API. The impact depends on the RBAC permissions of the service account. In the worst case (cluster-admin), the attacker has full control of the cluster. Kubernetes 1.24+ uses bound service account tokens with limited lifetime by default, which reduces (but does not eliminate) this risk.

Container security tools: what they catch

The container security tooling landscape is mature but fragmented. No single tool covers every aspect of container and Kubernetes security. Understanding what each category of tool catches and what it misses is essential for building a comprehensive security strategy.

A mature container security program combines tools from multiple categories. Image scanning in CI/CD catches known vulnerabilities before deployment. Admission controllers enforce policies at deploy time. Configuration auditors validate the cluster's security posture. Runtime monitoring detects active threats. And periodic penetration testing validates that all of these controls work together as intended.

Hardening checklist for Kubernetes deployments

The following checklist summarizes the key hardening measures for a production Kubernetes environment. It is organized by priority, starting with the controls that provide the most security value for the least effort.

Critical: address immediately

• No pods running in privileged mode (enforce with Pod Security Admission)
• No containers running as root (enforce runAsNonRoot: true)
• No hostPath mounts to sensitive paths (/, /etc, /var/run/docker.sock)
• Default service account tokens not auto-mounted (automountServiceAccountToken: false)
• RBAC does not grant cluster-admin to any application service account
• etcd encrypted at rest
• Kubernetes Dashboard not exposed without authentication
• Container images scanned for critical vulnerabilities before deployment
• No secrets committed to Git repositories or baked into image layers

High: address within 30 days

• NetworkPolicies deployed with default-deny in every namespace
• Egress restricted to required endpoints only
• All pods specify CPU and memory requests and limits
• RBAC scoped to specific resources and namespaces (no wildcards)
• Metadata service access blocked or restricted (IMDSv2, Workload Identity)
• Secrets managed through an external secrets manager (Vault, AWS Secrets Manager, etc.)
• Read-only root filesystem enabled for all application containers
• All capabilities dropped, specific capabilities added only as needed
• Base images pinned to specific versions, not latest
• Multi-stage Docker builds for all production images

Important: address within 90 days

• Admission controllers deployed (OPA Gatekeeper or Kyverno) with policies for image sources, pod security, and resource limits
• Container images signed and signatures verified at deployment
• Runtime security monitoring deployed (Falco or commercial equivalent)
• Seccomp profiles applied to all pods (at minimum, the default Docker profile)
• AppArmor or SELinux profiles applied to all pods
• SBOM generation integrated into CI/CD pipeline
• Audit logging enabled for all Kubernetes API requests
• Container-optimized host OS deployed (Bottlerocket, Flatcar, Talos)
• Pod-to-pod traffic encrypted (service mesh mTLS or CNI-level encryption)
• Regular RBAC audits scheduled (quarterly at minimum)

How this connects to your broader security program

Container and Kubernetes security does not exist in isolation. It is one layer of a defense-in-depth strategy that spans your entire infrastructure. The cloud platform your Kubernetes clusters run on needs its own security assessment. The CI/CD pipelines that build and deploy your container images are their own attack surface that requires hardening. The applications running inside your containers need application-level security testing regardless of how well the infrastructure is configured.

Compliance frameworks are catching up to containerized infrastructure. SOC 2 auditors now ask about container security controls. ISO 27001 Annex A controls map directly to Kubernetes hardening measures. PCI DSS 4.0 includes specific requirements for container and orchestration security. If your organization is pursuing or maintaining any of these certifications, your Kubernetes security posture will be evaluated.

The most effective approach is to integrate container security testing into your existing security program rather than treating it as a separate workstream. Image scanning belongs in your CI/CD pipeline. Kubernetes configuration audits belong in your regular security assessment cadence. Runtime monitoring belongs alongside your existing SIEM and incident response infrastructure.

Containerized infrastructure is not inherently more or less secure than traditional infrastructure. It is different. The security boundaries are different, the attack paths are different, and the tools and techniques for hardening are different. But the fundamental principles are the same: reduce attack surface, enforce least privilege, segment networks, manage secrets properly, monitor for anomalies, and test everything before an attacker tests it for you.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.