1. Container Security

Before diving specifically into ECS or EKS, it's important to reinforce common container security best practices:

• Trusted Images

- Use trusted registries (image repositories), such as Amazon ECR (Elastic Container Registry).

- Perform image scanning to detect vulnerabilities and keep images always up to date with security patches.

• Principle of Least Privilege

- Avoid running containers as the root user.

- Ensure that permissions (filesystem, network, etc.) are restricted to the minimum necessary.

• Separation of Responsibilities

- Maintain a clear separation between development and operations teams.

- Use CI/CD pipelines with security verification steps (scans, automated penetration tests, etc.).

---

2. Security on Amazon ECS

Amazon ECS is a container orchestration service that abstracts the complexity of managing servers or Kubernetes clusters, offering a more simplified experience for deploying containerized applications.

2.1 Execution Models: EC2 and Fargate

• EC2: You manually manage the infrastructure (EC2 instances) where containers will run.

- Best practices:

- Keep AMIs and operating systems up to date.

- Limit SSH access only to trusted networks or use Session Manager (instead of opening SSH ports).

- Use IAM roles for each EC2 instance to avoid storing credentials on disk.

• Fargate: AWS manages the underlying infrastructure, reducing the attack surface (no direct access to the host operating system).

- Best practices:

- Configure a private VPC for tasks that don't need direct internet access.

- Use restrictive security groups and/or network ACLs to isolate workloads.

- Manage logs and metrics with AWS CloudWatch or other platforms for continuous visibility.

2.2 IAM and Permissions

• IAM Roles for Tasks: Allow each ECS task to have the necessary permissions to access AWS resources (such as S3, DynamoDB, etc.) without sharing credentials.

- Ensure that only authorized containers can assume those specific roles.

- Apply the principle of least privilege to prevent unauthorized access to other services.

• Policies and Governance

- Use AWS Organizations and Resource Access Manager to define security policies at the organizational level, restricting actions in specific accounts.

- Monitor and review policies periodically, removing permissions that are no longer needed.

2.3 Network and Isolation

• Security Groups and ACLs

- Each ECS task (or EC2 instance in host mode) should have a security group that allows only essential traffic (for example, HTTP/HTTPS for front-end).

- In microservices scenarios, evaluate whether East-West communication (container to container) is necessary or should be restricted.

• VPC and Subnets

- Create public subnets only for tasks that require direct internet access (for example, a front-end).

- Use private subnets for back-end tasks and internal services, adding a NAT Gateway if they need internet access for updates or other external dependencies.

2.4 Secrets Management

• AWS Secrets Manager and AWS Systems Manager Parameter Store

- Do not store passwords or API keys in plain environment variables.

- Use secrets management services for rotation, protection, and access control.

- Configure the ECS task to retrieve secrets dynamically, reducing credential exposure.

2.5 Observability and Auditing (With AWS Services)

• CloudWatch Logs and AWS X-Ray

- Send application and container logs to CloudWatch for auditing and troubleshooting.

- Use AWS X-Ray to trace calls between microservices and gain visibility into application behavior and response times.

• AWS Config and CloudTrail

- Track configuration changes in AWS resources (ECS services, IAM roles, etc.).

- Monitor API activities to have a robust audit trail, identifying who did what and when.

---

3. Security on Amazon EKS

Amazon EKS is the managed Kubernetes service on AWS. It is recommended for teams that want greater flexibility and control over the Kubernetes ecosystem, including network customization, advanced RBAC (Role-Based Access Control) configurations, security plugins, and more.

3.1 Cluster Architecture and RBAC

• Managed Control Plane

- AWS manages the Kubernetes control plane, including scalability and security patches.

- Best practices: Configure access restrictions so that only roles or users authorized by your organization can interact with the Kubernetes API.

• RBAC (Role-Based Access Control)

- Carefully define permissions for users and service accounts within the cluster.

- Use namespaces to separate environments (dev, staging, production) and apply specific RBAC rules for each one.

• IAM Roles for Service Accounts (IRSA)

- Link Kubernetes service accounts to IAM roles, so that each application (pod) has only the necessary permissions.

- Avoid configuring broad permissions at the node (EC2 instance) level.

3.2 Node Security (Worker Nodes)

• EC2 and Fargate

- Just like in ECS, you can choose to run pods on EC2 instances or on AWS Fargate.

- When using EC2, keep the OS up to date and apply patches regularly.

- With Fargate, AWS manages most of the infrastructure, reducing the attack surface and facilitating compliance.

• Pod Segregation

- Use taints and tolerations to control where each pod runs.

- In high-security situations, consider using separate node groups for workloads with different requirements (for example, PCI workloads and general workloads).

3.3 Network Policies

• Kubernetes Network Policies

- Implement network policies to control traffic (ingress/egress) between pods and different namespaces.

- Reduce the possibility of a compromised pod communicating freely with other services.

• VPC CNI and Security

- The AWS VPC CNI plugin integrates pods directly into the VPC. Even so, maintain security group and ACL rules to control access.

- In some cases, combining Network Policies with solutions like Cilium or Calico can provide even more granular control.

3.4 Ingress and TLS

• Ingress Controllers

- When exposing services to the internet, configure an Ingress Controller (for example, AWS Load Balancer Controller).

- Enable TLS (HTTPS) to protect external and internal traffic whenever possible.

• Certificates and Cert Manager

- Automate certificate issuance and renewal using tools like cert-manager, integrated with ACM (AWS Certificate Manager) when feasible.

3.5 Observability and Security Monitoring

• CloudWatch Container Insights

- Enable Container Insights to capture metrics and logs from pods, services, and the Kubernetes cluster itself.

- Use dashboards to monitor cluster health and detect anomalies.

• GuardDuty and Security Hub

- Enable Amazon GuardDuty to detect malicious activities related to your EC2 nodes or suspicious API interactions.

- Consolidate security findings in AWS Security Hub, creating a centralized view for incident response.

---

4. Comparison: ECS vs EKS

The table below summarizes the main differences and points of attention in terms of security and operability:

| Criterion | Amazon ECS | Amazon EKS |

|-----------|------------|------------|

| Orchestration Model | AWS proprietary orchestrator (abstracts much of Kubernetes). | Managed Kubernetes, offering flexibility and open standard (easy portability). |

| Configuration Complexity | Simpler to configure (manages fewer components). | Steeper learning curve involving native Kubernetes concepts (RBAC, CRDs, etc.). |

| Control Plane Security | Managed by AWS; smaller configuration surface. | Managed Kubernetes control plane, but with greater need to configure RBAC, etc. |

| IAM for Containers | IAM Roles for Tasks. Simple and straightforward implementation. | IAM Roles for Service Accounts (IRSA). Requires a bit more configuration, but is powerful. |

| Network Policies | Approach focused on security groups, ACLs, and subnet design. | Native Kubernetes Network Policies (complemented by CNI and security plugins). |

| Ecosystem and Extensibility | Integrated with the AWS ecosystem, but with fewer plugins and add-ons available. | Broad Kubernetes ecosystem, various plugins, operators, and security tools. |

| Use Case Focus | Teams that want agility with less configuration overhead, and standard containerized applications. | Teams that need the power and customization of Kubernetes, with multiple services and complex integrations. |

Considerations:

• ECS is an excellent choice if you want simplicity, especially using Fargate, which greatly reduces the attack surface and management effort.
• EKS is valuable if you already have (or want to adopt) Kubernetes standardization, if you need great portability between environments, and if you require a broad ecosystem of security, monitoring, and microservices orchestration tools.