Container Security: What to Check in Docker and Kubernetes Environments

Containerisation changed the security model of application infrastructure in ways that are not always well understood. The isolation model that containers provide is real but limited: a container is not a virtual machine, and the boundaries between a container and its host, and between containers in the same cluster, have vulnerability classes that are specific to the container runtime and orchestration layer. Teams that move to containerised infrastructure without understanding those differences carry over the assumptions of the previous model and miss the risks introduced by the new one.

Container security is not a single problem. The attack surface spans the container image, the runtime configuration, the orchestration platform, the network configuration between containers and services, and the secrets and configuration management patterns used in the environment. Each layer has distinct findings. An assessment that only checks image vulnerability scores is missing the majority of the actual exposure.

Container Image Security

The starting point for container security is the image. A container image is built from a base layer, typically a minimal operating system image, with application code and dependencies added on top. The base layer has its own vulnerability history, and if it is not updated regularly, the containers built from it carry those vulnerabilities into production. The application dependencies layered on top add their own surface area. Image scanning tools compare the contents of an image against known vulnerability databases and report what is present and vulnerable before the image is deployed.

Beyond vulnerability scanning, image security includes the Dockerfile practices used to build the image. Running containers as root is a common finding: an application that runs as root inside a container has broader access to the host system if the container is compromised. Using a minimal base image reduces the attack surface by limiting what software is present in the container. Multi-stage builds allow build-time tools and dependencies to be excluded from the final production image. Avoiding the storage of secrets in image layers is essential, since image layers are readable by anyone with access to the registry. These are Dockerfile-level practices that an image scanner does not check and that require deliberate attention during build pipeline design.

Kubernetes Configuration

Kubernetes introduces a substantial configuration surface. The most common findings in Kubernetes security assessments relate to permissive configurations that were set for convenience during development and then carried into production. Pods running as root, containers with elevated capabilities, overly permissive role-based access control bindings, and containers with access to the host network or host filesystem are all common. Each of these represents a privilege escalation path that an attacker with access to one container could use to move laterally within the cluster or reach the host.

Pod security standards or admission controllers should be configured to enforce baseline security requirements across all workloads. Network policies control which pods can communicate with which other pods and should be configured to limit lateral movement: a compromised web application container should not have network access to the database layer without that access being explicitly permitted. The Kubernetes API server should be configured to restrict what it accepts and from whom. Role-based access control should follow the principle of least privilege, with service accounts having only the permissions their associated workloads actually require.

Runtime Security and Secrets Management

Runtime security addresses what happens after a container is running. A container that passes all pre-deployment checks can still be exploited through vulnerabilities in the application code. Runtime monitoring observes container behaviour against an established baseline and alerts on anomalous activity: a web application container that starts making outbound network connections to external addresses, spawning shell processes, or reading files outside its expected paths is exhibiting behaviour consistent with compromise. Runtime monitoring tools provide that visibility.

Secrets management in container environments is a persistent source of findings. Secrets passed as environment variables are accessible to every process in the container, visible in orchestration platform interfaces, and may be logged by application frameworks. Secrets baked into images are readable by anyone with registry access. The appropriate pattern is to use a dedicated secrets management service that injects secrets at runtime and restricts access to specific workloads. The implementation of that pattern is more complex than the alternatives, which is why the simpler and less secure approaches are common findings.

Supply Chain and Registry Security

Container security extends to the supply chain that produces images. Third-party base images from public registries may contain malicious packages or be updated with malicious content after an initial security review. Pinning images to specific digest hashes rather than mutable tags prevents unexpected updates from altering the running environment. Using a private registry with access controls limits who can pull images and provides a point for enforcing image signing and provenance requirements.

If you are building or operating containerised applications and want to understand the security posture of your environment, we can assess the full stack from image build practices to runtime configuration. Contact us at info@cyberlinx.com.au to discuss what a container security assessment covers for your environment.