Containers Are Not Automatically Secure

Containers provide process isolation, not security isolation. A misconfigured container can expose the host system, leak secrets, or become an attack vector into your cluster. At Nexis Limited, container security is integrated into our CI/CD pipeline and runtime monitoring across all Kubernetes deployments.

Image Security

Use Minimal Base Images

Start with minimal base images like Alpine Linux, distroless images, or scratch. Smaller images have fewer packages, which means fewer potential vulnerabilities. A Node.js application on Alpine is roughly 50MB compared to 900MB on a full Debian image — and has a fraction of the CVE surface area.

Scan Images for Vulnerabilities

Scan container images in your CI/CD pipeline before pushing to a registry. Tools like Trivy, Grype, and Snyk Container identify known CVEs in OS packages and application dependencies. Fail the pipeline for critical or high-severity vulnerabilities. Re-scan images regularly — new vulnerabilities are discovered in existing packages daily.

Pin Image Versions

Never use the "latest" tag in production Dockerfiles or Kubernetes manifests. Pin specific image versions (node:20.11.0-alpine) to ensure reproducible builds and prevent unexpected changes when upstream images are updated.

Dockerfile Best Practices

  • Run containers as a non-root user. Add USER directive to your Dockerfile.
  • Use multi-stage builds to avoid including build tools and source code in production images.
  • Set the filesystem to read-only where possible using readOnlyRootFilesystem in Kubernetes.
  • Do not install unnecessary packages — no curl, wget, or shell tools in production images unless required.
  • Copy only the necessary files — use .dockerignore to exclude source code, tests, and documentation.

Kubernetes Security

Pod Security Standards

Enforce Pod Security Standards (PSS) at the namespace level to prevent privileged containers, host network access, and privilege escalation. Use the "restricted" profile for production workloads.

Network Policies

By default, all pods in a Kubernetes cluster can communicate with each other. Define NetworkPolicies to restrict traffic — allow only the traffic your application actually needs. Follow the principle of least privilege: deny all traffic by default, then allow specific flows.

RBAC

Configure Role-Based Access Control (RBAC) with the principle of least privilege. Service accounts should have the minimum permissions needed. Avoid using the default service account — create dedicated service accounts for each workload with specific roles.

Secrets Management

  • Never store secrets in container images, environment variable definitions, or source code.
  • Use Kubernetes Secrets encrypted at rest with a KMS provider.
  • Consider external secrets managers (Vault, AWS Secrets Manager) with the External Secrets Operator for production deployments.
  • Rotate secrets regularly and implement automatic rotation where possible.

Runtime Security

  • Monitor container behavior with tools like Falco that detect anomalous activity (unexpected process execution, file access, network connections).
  • Implement resource limits (CPU, memory) to prevent container resource exhaustion and denial-of-service attacks.
  • Use admission controllers (OPA Gatekeeper, Kyverno) to enforce policies at deployment time — prevent non-compliant workloads from being deployed.

Conclusion

Container security is a layered practice — secure images at build time, enforce security policies at deployment time, and monitor behavior at runtime. Automate security checks in your CI/CD pipeline so that insecure configurations are caught before they reach production.

Securing your container infrastructure? Our DevOps team implements comprehensive container security.