If you type “container security best practices” into a search engine, you will get Kubernetes. Pod security standards, RBAC, network policies, admission controllers, EKS hardening guides. This is not wrong — Kubernetes security deserves the attention it gets. But it creates a real blind spot for a large population of AWS teams whose primary compute surface is Amazon ECS, not Kubernetes at all.
ECS has its own security model, and it deserves the same rigor as its Kubernetes counterpart. This article covers the checks that matter most: task definitions, task IAM roles, service networking, and image provenance — the surface area that most generic container security content skips entirely.
Why ECS Gets Overlooked
ECS is AWS’s own container orchestration service, and it runs a significant share of containerized workloads in the wild — arguably more than EKS for teams that do not need full Kubernetes flexibility. It is simpler to operate, has fewer moving parts, and integrates tightly with the rest of AWS.
That simplicity is also why it gets less security attention. There is no CNCF working group publishing ECS hardening benchmarks with the same visibility as Kubernetes equivalents. Security tooling vendors build for the platform with the loudest community first, and that has historically been Kubernetes. The result: teams running ECS at scale often assume their container security is “handled” because they have some CSPM tool connected, when that tool’s ECS-specific coverage may be thin.
Task Definition Security: Where Most of the Risk Lives
The ECS task definition is the JSON (or console-equivalent) specification of how a container runs. It is also where the most common and most consequential misconfigurations appear.
Privileged mode. A container running with privileged: true has access approaching that of the host. This should almost never be necessary for an application workload, and every instance of it deserves scrutiny.
Host networking and host PID. Setting networkMode: host or sharing the host’s process namespace collapses container isolation. A compromised container in this mode can see and potentially interact with processes and network interfaces outside its own boundary.
Excessive Linux capabilities. Task definitions can add capabilities beyond the container runtime default. CAP_SYS_ADMIN, CAP_NET_ADMIN, and similar additions are frequently copied from a Stack Overflow answer that solved an unrelated problem and never removed once the immediate issue was fixed.
Read-write root filesystem. By default, a container’s root filesystem is writable. Setting readonlyRootFilesystem: true where the application does not need to write to its own filesystem sharply limits what a compromised container can tamper with or persist.
Missing logging configuration. A task definition without an awslogs or FireLens log driver means container stdout/stderr — and any security-relevant events an application logs — simply disappears. This is invisible until you need those logs during an incident and discover they were never captured.
Secrets as plaintext environment variables. Database credentials, API keys, and tokens hardcoded directly in the environment block of a task definition are visible to anyone who can describe the task definition via the API or console — a far larger audience than anyone intends. AWS Secrets Manager and Systems Manager Parameter Store references exist specifically to avoid this, via the secrets block instead of environment.
Task IAM Roles: The Quiet Over-Privilege Problem
Every ECS task can assume two distinct roles: the task execution role (used by the ECS agent to pull images and write logs) and the task role (used by the application code running inside the container to call AWS APIs).
These are frequently over-scoped. A task role granted broad S3 access “to make the initial integration work” during development often survives unchanged into production, months later, long after the specific bucket and actions needed were identified. The practical consequence: if the container is compromised — through a dependency vulnerability, a misconfigured endpoint, or any other route — the attacker inherits whatever that task role can do across the account. An over-permissive task role is functionally equivalent to an over-permissive Kubernetes service account, and it deserves the same least-privilege discipline, but it gets reviewed far less often because ECS IAM tooling and guidance are less visible than their Kubernetes RBAC counterparts.
The fix is not exotic: scope task roles to the specific actions and resources the application actually calls, using IAM policy conditions where possible, and review them on a schedule rather than only at creation time.
Service Networking: Security Groups and Subnet Placement
An ECS service attaches to security groups and runs in specified subnets. Two patterns recur:
Overly broad security groups. A security group allowing inbound traffic from 0.0.0.0/0 on ports beyond what the service’s load balancer requires is more permissive than almost any service needs. Security groups should be scoped to the minimum required source and port.
Public subnet placement without justification. Services do not need to run in public subnets simply because they eventually receive internet traffic — that traffic should typically arrive via a load balancer in the public subnet, with the ECS tasks themselves in private subnets. A task running directly in a public subnet, reachable without an intermediary, is a larger exposure than the architecture usually requires.
Image Provenance: What Is Actually Inside the Container
A container is only as trustworthy as the image it runs. Common gaps:
- Images pulled from public registries without a vulnerability scan performed before deployment.
- No digest pinning — referencing a mutable tag like
:latestrather than an immutable digest, meaning the same task definition can silently run different code over time as the tag is updated upstream. - No record of what changed between image versions, making it hard to correlate a new vulnerability with when it was introduced.
Scanning images before they reach ECS — ideally as a gate in the CI/CD pipeline that builds them — catches known vulnerabilities before they run in production, rather than discovering them after the fact.
A Practical ECS Security Checklist
- No task definitions run in privileged mode without documented justification.
- Host networking and host PID are disabled unless architecturally required.
- Linux capabilities are limited to what the application actually needs.
- Root filesystems are read-only wherever the application permits it.
- Every task definition has a logging configuration (
awslogsor FireLens). - Secrets are referenced via Secrets Manager or Parameter Store, never as plaintext environment variables.
- Task roles and task execution roles are scoped to least privilege and reviewed periodically.
- Security groups attached to ECS services are scoped to the minimum required source and port.
- Tasks run in private subnets behind a load balancer, not directly in public subnets.
- Images are scanned for vulnerabilities before deployment and referenced by digest, not mutable tag.
The Underlying Principle
None of this is unique or exotic security thinking — it is the same least-privilege, minimal-attack-surface reasoning that governs good Kubernetes security. What is different is visibility. Because the ecosystem’s attention skews toward Kubernetes, ECS-specific guidance and tooling coverage are thinner, and teams running ECS at scale can end up with a false sense of coverage from generic container security tools that were built with Kubernetes’ shape in mind.
If ECS is where most of your containers run, it deserves to be treated as the primary surface it is — not a secondary concern behind whatever share of your workloads happen to run on EKS. Checking task definitions, IAM roles, networking, and image provenance with the same depth you would apply to a Kubernetes cluster is the fundamental fix, and it does not require adopting Kubernetes to get there.
People Also Read
- Top 12 Container Security Best Practices
- The Ultimate Guide to Cloud Workload Protection: 5 Key Strategies
- CSPM for ECS-Heavy AWS Workloads: Small Security Teams
- CSPM for ECS Task Definitions: Securing the Container Surface That Isn’t Kubernetes
- Top 15 Cloud Misconfigurations in 2026 and How to Fix Them
