Docker & Kubernetes Code Audit

Common Container Audit Findings

The most frequent finding: containers running as root with full base images. Alpine or distroless images cut attack surface by 90%. Running as a non-root user prevents container escape vulnerabilities. These changes are simple but almost never present in AI-generated Dockerfiles.

Resource limits are either missing or wrong. Without limits, a single misbehaving pod consumes all node resources and takes down neighboring workloads. With wrong limits - usually copy-pasted from examples - pods get OOM-killed during normal operation or sit idle with reserved resources nobody else can use. We analyze actual utilization and set limits based on real data.

Health checks are missing or superficial. A liveness probe that returns 200 while the application can’t reach its database isn’t useful. We implement readiness probes that verify actual functionality and liveness probes that detect genuine deadlocks, not just process existence.

Our Container Audit Approach

We start with the Dockerfiles. Build stages, base images, layer ordering, caching behavior, and final image contents. We check for secrets baked into layers, unnecessary build tools in production images, and non-deterministic builds that produce different images from the same source.

Kubernetes manifests get a systematic review. Every Deployment, Service, ConfigMap, and Secret is checked against best practices. Security contexts, resource requests and limits, pod disruption budgets, and affinity rules. We use tools like kube-score and Polaris alongside manual review because automated tools miss context-specific issues.

We analyze runtime behavior too. Actual CPU and memory usage versus configured limits. Pod restart frequency and reasons. Network traffic patterns that inform network policy design. The gap between configuration and reality is where most problems hide.

Security and RBAC Findings

RBAC misconfigurations are nearly universal. Service accounts with cluster-admin privileges, pods mounting the default service account token when they never call the Kubernetes API, and overly broad ClusterRoleBindings that grant namespace-scoped permissions cluster-wide. We audit every ServiceAccount, Role, and RoleBinding to enforce least-privilege access. If a pod only needs to read ConfigMaps in its own namespace, it gets exactly that permission and nothing more.

We also examine ingress configurations and TLS termination. Expired certificates, missing HSTS headers, and wildcard ingress rules that expose internal services are common finds. Network policies are reviewed to ensure east-west traffic within the cluster is restricted to explicitly allowed paths. A compromised pod in one namespace should not be able to reach pods in another without a deliberate policy allowing it.

What Changes After the Audit

Your containers become smaller, faster, and more secure. Images that were 1.2GB shrink to under 100MB. Build times drop because layers are properly ordered and cached. Security scanners stop flagging known vulnerabilities in packages your application doesn’t use.

Kubernetes workloads become stable. Pods stop getting OOM-killed because limits match actual usage. Scheduling improves because requests reflect real resource needs. Health checks catch failures before users do. Network policies restrict traffic to only what’s necessary. The cluster runs the same workloads on less infrastructure because resources are allocated efficiently.