É fácil pensar que, ao trabalhar com contentores, a segurança do host deixa de importar. É precisamente o contrário: cada nó de Kubernetes é uma máquina que arranca a partir de uma imagem, e uma falha no host compromete todos os pods que aloja. A AMI do nó é, por isso, uma peça crítica de segurança.
Tem três caminhos: usar as AMIs otimizadas oficiais tal como estão, usá-las como base e personalizá-las, ou construir a sua. Para produção a sério, personalizar ou construir sobre uma base endurecida é o recomendado.
O que deve ter uma boa AMI de nó
- Base otimizada para o runtime de contentores, com containerd e kubelet corretamente configurados.
- Hardening CIS do sistema operativo e, quando aplicável, do próprio CIS Benchmark for Kubernetes.
- Patches em dia do kernel e dos componentes, com reconstrução periódica.
- Agentes necessários —logs, métricas, segurança— pré-instalados para um arranque rápido.
- Sem segredos nem credenciais embutidos; identidade via IAM Roles for Service Accounts (IRSA) ou equivalente.
- Configuração mínima: elimine pacotes e serviços de que um nó não precisa.
Opções de imagem para EKS
| Opção | Vantagem | Quando escolher |
|---|---|---|
| AMI EKS otimizada (AL2023) | Oficial, mantida pela AWS | Ponto de partida geral |
| Bottlerocket | SO mínimo orientado a contentores, imutável | Segurança máxima e menor superfície |
| AMI personalizada | Controlo total do hardening e dos agentes | Requisitos de conformidade rigorosos |
Escolha a base do nó conforme o seu equilíbrio entre controlo e comodidade.
Bottlerocket: contentores primeiro
O Bottlerocket é um sistema operativo minimalista da AWS pensado exclusivamente para executar contentores. A sua superfície de ataque é diminuta, é imutável e atualiza-se por imagem —não por patch a quente—, o que encaixa na perfeição com a filosofia de infraestrutura imutável. Se a sua prioridade é a segurança do nó com o mínimo esforço de manutenção, merece uma avaliação séria.
Atualizar nós sem dor
Uma AMI de nó endurecida só serve se mantiver os nós em dia. O padrão imutável brilha aqui:
- Substitua, não faça patch: publique uma nova versão de AMI e rode os nós.
- Rolling update do grupo de nós: drene com cordon e drain e substitua nó a nó.
- Managed Node Groups ou Karpenter para automatizar a substituição com AMIs novas.
- PodDisruptionBudgets para que a rotação não afete a disponibilidade dos seus serviços.
Erros frequentes
- Usar a AMI otimizada por omissão durante meses sem a atualizar.
- Embutir credenciais do cluster na imagem em vez de usar identidade federada.
- Esquecer o hardening do próprio kubelet e das permissões do sistema de ficheiros.
- Não limitar o acesso SSH aos nós: idealmente, zero SSH e acesso apenas via SSM.
Perguntas frequentes
Preciso de uma AMI personalizada ou basta a otimizada do EKS?
Para começar, a otimizada oficial é um bom ponto de partida. Se tiver requisitos de conformidade ou segurança rigorosos, personalize-a ou construa a sua com hardening e agentes próprios.
O Bottlerocket substitui uma AMI Linux normal?
Para nós que só executam contentores, sim: oferece menor superfície de ataque e atualização imutável. Não é adequado a cargas que precisem de um SO de uso geral.
Como atualizo os nós quando publico uma AMI nova?
Com um rolling update do grupo de nós: são drenados e substituídos de forma progressiva, respeitando os PodDisruptionBudgets para não afetar o serviço.
Na imaxe.cloud desenhamos imagens base endurecidas, ideais como alicerce dos seus nós de Kubernetes.
