Beyond Migration Part 2: Practical AWS Container Platform Security Controls for Real-World Resilience

In Part 1, we covered why an insecure AWS container platform can drag your whole business down—breaches, fines, outages, the lot. Now, let’s flip the script and discuss how to lock things down without killing your delivery speed. These are the AWS container best practices.

Stop Running Containers as Root – Seriously

Running containers with root privileges is a significant and unnecessary risk. If an attacker compromises an application running as root within a container, they effectively have root privileges. Container isolation isn’t a foolproof security measure. Exploiting vulnerabilities in the container runtime or the host kernel can allow attackers to escape the container and gain root access to the host system.

Scenario 2: Real-world “Root Container” blow-up

How to avoid it

• USER directive – Put USER 10001 (or similar) in every Dockerfile.
• Pod Security Admission – In EKS/Kubernetes 1.25+, use the restricted profile to block root images; add OPA Gatekeeper or Kyverno for custom rules.
• Read-only root FS – Add readOnlyRootFilesystem: true to your pod specs.
• Drop caps – Start with drop: [“ALL”], then add back only what the app really needs.

Deep Dive: Key Security Pillars Post-Migration (Beyond the Basics)

While the foundational AWS security services (IAM, Security Groups, CloudTrail, GuardDuty, ECR Scanning) are essential, a mature container security strategy integrates broader industry best practices and considers specialised tooling.

1. Comprehensive Image Assurance (CNCF & OWASP Alignment)

Ensuring container images are free from known vulnerabilities reduces the risk of breaches that could disrupt services or trigger costly compliance incidents.

• • Trusted Base Images: Mandate hardened, minimal base images from reputable sources (AWS-provided distroless images, official vendor images, or internally vetted “golden” images). Avoid pulling from random public repos.
  • CI/CD Scanning Stages: IScan inside the pipeline with Wiz, Trivy, Snyk, Prisma Cloud, or similar, then rely on Amazon ECR Enhanced Scanning (now powered by Amazon Inspector) for continuous “on-push” and scheduled registry scans. These tools look beyond CVEs―catching misconfigurations, embedded secrets, and malware.
  • Software Bill of Materials (SBOM): Keep an SBOM for every image so you can instantly locate the blast radius when a new CVE drops.
  • Image Signing & Verification: Use Notary v2 or AWS Signer so only trusted, tamper-free images reach the cluster.
  • OWASP Docker top 10: Stay on top of risks such as insecure configs, vulnerable libraries, and weak logging/monitoring—and bake mitigations into your pipeline.

2. Runtime Defense & Threat Detection

Minimising permissions limits the blast radius of any compromise, protecting sensitive data and reducing potential operational downtime.

• • Non-Root Execution: USER directives in Dockerfiles plus Pod Security Admission (or Kyverno/OPA Gatekeeper admission webhooks) block root containers.
  • Read-Only Root FS: Make the root filesystem read-only so malware can’t write itself into place.
  • Drop Unnecessary Capabilities: Start with drop: [“ALL”], then add back only what the app truly needs.
  • explicitly required by the container (e.g., NET_ADMIN, SYS_ADMIN).
  • Runtime Threat Detection & Prevention: Tools from Aqua, Palo Alto Networks, Sysdig, and Falco — now a CNCF graduated project, provide:
    • Behavioral Anomaly Detection: Profiling normal container behavior and alerting on deviations (e.g., unexpected network connections, process execution, file access).
    • Exploit Prevention: Blocking known exploit techniques at the process and network level within the container.
    • File Integrity Monitoring (FIM): Alerting on unauthorised changes to critical files within the container or on the host.
    • Incident Response Capabilities: Tools to help isolate compromised containers and gather forensic data.
  • Network Segmentation & Microsegmentation:
    • Kubernetes Network Policies (EKS): Default-deny with Calico (OSS) or Cilium (CNCF-graduated); if you run Security Groups for Pods, combine them with NetworkPolicies for actual least-privilege east-west traffic.
    • AWS Security Groups & NACLs: Still your outer guardrails at VPC and node layers.
    • Service Mesh (e.g., Istio, Linkerd – CNCF projects, AWS App Mesh): This can provide mTLS for secure pod-to-pod communication, fine-grained traffic control, and observability.

3. Secure Orchestration & Control Plane Hardening (EKS Focus)

Locking down control plane access and securing nodes prevents attackers from taking control of your environment — protecting service uptime and business continuity.

• API Server Access: Keep it private, authenticate via IAM/OIDC, and authorise tightly with RBAC.
• Audit Logging: Ensure Kubernetes audit logs are enabled and shipped to CloudWatch Logs, and actively monitor for suspicious API calls or authorisation failures.
• etcd Security: Guard it with IAM/network policies to stop compromised pods from prying.
• Worker Node Hardening: Patch EKS-optimised or Bottlerocket AMIs regularly, use SSM instead of SSH, and track CIS benchmark drift with Inspector or external scanners.

4. Secrets Management Excellence

Proper secrets management limits the blast radius of breaches and protects sensitive customer or financial data from exposure.

• Dedicated Secrets Stores: AWS Secrets Manager or HashiCorp Vault beats env vars every time.
• IRSA + Secrets Store CSI Driver: Mount Secrets Manager values as ephemeral volumes, with per-pod IAM roles for least-privilege access.
• Rotation and Auditing: Turn on automatic rotation and log every secrets read.

5. Continuous Monitoring, Logging, and Alerting

Real-time visibility and alerting help detect threats early, reducing response times and minimising business disruption.

• Centralised & Correlated Logging: Aggregate container stdout/stderr, app logs, host metrics, K8s audit logs, and AWS signals (CloudTrail, GuardDuty, VPC Flow Logs) into OpenSearch, Splunk, or your SIEM.
• Actionable Alerts: Page on GuardDuty EKS findings, critical CVEs, suspicious API calls, and runtime anomalies—minutes matter.
• Regular Security Audits & Penetration Testing: Hit the cluster quarterly, following AWS’s pen-test policy, to catch drift before attackers do.

The Path Forward: Embedding Security into Your Container DNA

Securing your AWS container platform should never be considered a “one-off” project. I’ve seen numerous clients come to me for a security audit, saying it was built on a “secure foundation” and stating they believe it’s very secure. Only after that audit did they realise the security of what they built had drifted immensely from its original foundation and setup. Security needs to be a continuous process of improvement and adaptation. It requires a cultural shift towards DevSecOps, working closely between development, operations, and security teams, and an understanding that security is an enabler of business agility, not a blocker.

BLUF (Bottom Line Up Front): By taking a defense-in-depth approach, embracing “shift left” principles, understanding the threat landscape specific to containers, and using the rich ecosystem of AWS services and specialised vendor solutions, you can turn your container platform from a target into a resilient and secure foundation for your applications.