1. Segurança em container

Antes de mergulharmos especificamente em ECS ou EKS, é importante reforçar as boas práticas comuns de segurança em container:

• Imagens confiáveis

- Utilize registries (repositórios de imagens) confiáveis, como o Amazon ECR (Elastic Container Registry).

- Faça image scanning para detectar vulnerabilidades e manter as imagens sempre atualizadas com patches de segurança.

• Princípio do mínimo privilégio

- Evite executar container como usuário root.

- Garanta que as permissões (filesystem, rede, etc.) estejam restritas ao mínimo necessário.

• Segregação de responsabilidades

- Mantenha uma separação clara entre equipes de desenvolvimento e operações.

- Use pipelines de CI/CD com etapas de verificação de segurança (scans, testes de penetração automatizados, etc.).

---

2. Segurança no Amazon ECS

O Amazon ECS é um serviço de orquestração de container que abstrai a complexidade de gerenciar servidores ou clusters Kubernetes, oferecendo uma experiência mais simplificada na implantação de aplicações em container.

2.1 Modelos de Execução: EC2 e Fargate

• EC2: Você gerencia manualmente a infraestrutura (instâncias EC2) onde os containers serão executados.

- Boas práticas:

- Mantenha as AMIs e sistemas operacionais atualizados.

- Limite o acesso SSH somente para redes confiáveis ou use Session Manager (no lugar de abrir portas de SSH).

- Utilize IAM roles para cada instância EC2 a fim de evitar armazenamento de credenciais em disco.

• Fargate: AWS gerencia a infraestrutura subjacente, reduzindo a superfície de ataque (sem acesso direto ao sistema operacional host).

- Boas práticas:

- Configure VPC privada para as tarefas que não precisem de acesso direto à internet.

- Utilize security groups restritivos e/ou ACLs de rede para isolar as workloads.

- Gerencie logs e métricas com AWS CloudWatch ou outras plataformas para ter visibilidade contínua.

2.2 IAM e Permissões

• IAM Roles for Tasks: Permitem que cada tarefa ECS tenha as permissões necessárias para acessar recursos AWS (como S3, DynamoDB, etc.) sem compartilhar credenciais.

- Garanta que apenas os containers autorizados possam assumir aquelas roles específicas.

- Aplique o princípio do menor privilégio para evitar acesso indevido a outros serviços.

• Policies e Governance

- Utilize AWS Organizations e Resource Access Manager para definir políticas de segurança em nível organizacional, restringindo ações em contas específicas.

- Monitore e revise políticas periodicamente, removendo permissões que não sejam mais necessárias.

2.3 Rede e Isolamento

• Security Groups e ACLs

- Cada tarefa ECS (ou instância EC2 em modo de host) deve ter um security group que permita apenas o tráfego essencial (por exemplo, HTTP/HTTPS para front-end).

- Em cenários de microserviços, avalie se é necessário permitir comunicação East-West (container para container) ou se deve restringir.

• VPC e Subnets

- Crie subnets públicas apenas para tarefas que requerem acesso direto da internet (por exemplo, um front-end).

- Utilize subnets privadas para tarefas de back-end e serviços internos, adicionando um NAT Gateway se precisarem acessar a internet para atualizações ou outras dependências externas.

2.4 Gerenciamento de Segredos

• AWS Secrets Manager e AWS Systems Manager Parameter Store

- Não armazene senhas ou chaves de API em variáveis de ambiente simples.

- Use serviços de gerenciamento de segredos para rotação, proteção e controle de acesso.

- Configure a tarefa ECS para recuperar segredos dinamicamente, reduzindo a exposição de credenciais.

2.5 Observabilidade e Auditoria (Com serviços AWS)

• CloudWatch Logs e AWS X-Ray

- Envie logs das aplicações e containers para o CloudWatch para auditoria e troubleshooting.

- Utilize o AWS X-Ray para rastrear chamadas entre microserviços e obter visibilidade do comportamento e tempo de resposta das aplicações.

• AWS Config e CloudTrail

- Acompanhe mudanças de configuração nos recursos AWS (ECS services, roles IAM etc.).

- Monitore atividades de API para ter um trilho de auditoria robusto, identificando quem fez o quê e quando.

---

3. Segurança no Amazon EKS

O Amazon EKS é o serviço gerenciado de Kubernetes na AWS. É recomendado para times que desejam ter maior flexibilidade e controle sobre o ecossistema Kubernetes, incluindo customização de rede, configurações avançadas de RBAC (Role-Based Access Control), plugins de segurança, entre outros.

3.1 Arquitetura do Cluster e RBAC

• Control Plane Gerenciado

- A AWS gerencia o plano de controle (control plane) do Kubernetes, incluindo escalabilidade e patches de segurança.

- Boas práticas: Configurar restrições de acesso para somente roles ou usuários autorizados pela sua organização conseguirem interagir com o Kubernetes API.

• RBAC (Role-Based Access Control)

- Defina cuidadosamente as permissões de usuários e service accounts dentro do cluster.

- Use namespaces para separar ambientes (dev, staging, produção) e aplique regras de RBAC específicas para cada um.

• IAM Roles for Service Accounts (IRSA)

- Vincule service accounts do Kubernetes a roles IAM, para que cada aplicação (pod) tenha apenas as permissões necessárias.

- Evite configurar permissões amplas em nível de nó (EC2 instance).

3.2 Segurança de Nós (Worker Nodes)

• EC2 e Fargate

- Assim como no ECS, você pode escolher executar os pods em instâncias EC2 ou no AWS Fargate.

- Ao usar EC2, mantenha o SO atualizado e aplique patches regularmente.

- Em Fargate, a AWS gerencia a maior parte da infraestrutura, reduzindo a superfície de ataque e facilitando a conformidade.

• Segregação de Pods

- Use taints e tolerations para controlar onde cada pod roda.

- Em situações de alta segurança, considere usar grupos de nós (node groups) separados para workloads com diferentes requisitos (por exemplo, workloads PCI e workloads gerais).

3.3 Network Policies

• Kubernetes Network Policies

- Implemente network policies para controlar o tráfego (ingress/egress) entre pods e namespaces diferentes.

- Reduza a possibilidade de um pod comprometido se comunicar livremente com outros serviços.

• VPC CNI e Segurança

- O plugin AWS VPC CNI integra pods diretamente à VPC. Mesmo assim, mantenha regras de security group e ACL para controlar acesso.

- Em alguns casos, combinar Network Policies com soluções como Cilium ou Calico pode dar ainda mais granularidade de controle.

3.4 Ingress e TLS

• Ingress Controllers

- Ao expor serviços para internet, configure um Ingress Controller (por exemplo, AWS Load Balancer Controller).

- Habilite TLS (HTTPS) para proteger o tráfego externo e interno, sempre que possível.

• Certificados e Cert Manager

- Automatize a emissão e renovação de certificados usando ferramentas como o cert-manager, integrado ao ACM (AWS Certificate Manager) quando for viável.

3.5 Observabilidade e Security Monitoring

• CloudWatch Container Insights

- Ative Container Insights para capturar métricas e logs de pods, serviços, e do próprio cluster Kubernetes.

- Use dashboards para acompanhar o estado do cluster e detectar anomalias.

• GuardDuty e Security Hub

- Ative o Amazon GuardDuty para detectar atividades maliciosas relacionadas a seus nós EC2 ou interações de API suspeitas.

- Consolide achados de segurança no AWS Security Hub, criando uma visão centralizada para resposta a incidentes.

---

4. Comparativo: ECS x EKS

A tabela abaixo resume as principais diferenças e pontos de atenção em termos de segurança e operacionalidade:

| Critério | Amazon ECS | Amazon EKS |

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

| Modelo de Orquestração | Orquestrador proprietário da AWS (abstrai boa parte do Kubernetes). | Kubernetes gerenciado, oferecendo flexibilidade e padrão aberto (fácil portabilidade). |

| Complexidade de Configuração | Mais simples de configurar (gerencia menos componentes). | Maior curva de aprendizado por envolver conceitos nativos de Kubernetes (RBAC, CRDs, etc.). |

| Segurança do Control Plane | Gerenciado pela AWS; menor superfície de configuração. | Control plane Kubernetes gerenciado, mas com maior necessidade de configurar RBAC, etc. |

| IAM para Container | IAM Roles for Tasks. Implementação simples e direta. | IAM Roles for Service Accounts (IRSA). Requer um pouco mais de configuração, mas é poderoso. |

| Network Policies | Abordagem focada em security groups, ACLs e design de subnets. | Kubernetes Network Policies nativas (complementadas por CNI e plugins de segurança). |

| Ecossistema e Extensibilidade | Integrado ao ecossistema da AWS, porém com menos plugins e add-ons disponíveis. | Ecossistema amplo do Kubernetes, diversos plugins, operadores e ferramentas de segurança. |

| Foco de Uso | Times que desejam agilidade com menos overhead de configuração, e aplicações containerizadas padrão. | Times que necessitam do poder e customização do Kubernetes, com múltiplos serviços e integrações complexas. |

Considerações:

• ECS é uma ótima escolha se você quer simplicidade, especialmente usando o Fargate, que reduz muito a superfície de ataque e esforço de gerenciamento.
• EKS é valioso se você já possui (ou deseja adotar) padronização em Kubernetes, se precisa de grande portabilidade entre ambientes e se requer um ecossistema amplo de ferramentas de segurança, monitoramento e orquestração de microserviços.