Principais pontos de segurança para provisionar uma aplicação no Amazon ECS e no Amazon EKS

Luiz Machado

Luiz Machado

— 5 min read

1. Segurança em 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.

Read more