Principais pontos de segurança para provisionar uma aplicação no Amazon ECS e no Amazon EKS
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.
- Boas práticas:
- 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.
- Boas práticas:
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.