Segurança de Contêineres e Kubernetes

Os contêineres compartilham o núcleo do host, o que os torna menos isolados do que as máquinas virtuais. A segurança de contêineres abrange: higiene das imagens (sem pacotes vulneráveis), proteção em tempo de execução (detecção de comportamento anormal), política de rede (restrição da comunicação entre pods) e configuração do RBAC.

O Trivy verifica imagens de contêiner em busca de CVEs de pacotes do OS, vulnerabilidades de dependências de aplicações, configurações incorretas e segredos. Integre-o ao CI/CD para bloquear imagens com vulnerabilidades críticas antes que cheguem à produção.

Utilize imagens base mínimas (alpine, distroless). Execute como usuário sem privilégios de root (USER 1000). Evite COPY . . — seja específico. Compilações em vários estágios reduzem o tamanho da imagem final. Verifique antes de enviar. Nunca codifique diretamente segredos ou credenciais nas camadas.

O RBAC do Kubernetes controla o acesso ao servidor de API. ClusterRoles e funções definem permissões sobre recursos (pods, segredos e implantações). ClusterRoleBindings e RoleBindings as atribuem a usuários, grupos ou ServiceAccounts. Evite cluster-admin, exceto para automação.

O PSS define três perfis: Privilegiado (sem restrições), Linha de base (restrições mínimas) e Restrito (reforçado). Aplique-os por meio dos rótulos de espaço de nomes do controlador de admissão PodSecurity. O perfil Restrito impede a execução como root, não permite elevação de privilégios e exige sistemas de arquivos somente leitura.

Por padrão, todos os pods podem se comunicar com todos os outros pods. As NetworkPolicies do Kubernetes definem regras de entrada e saída para cada seletor de pods. Implemente políticas que neguem tudo por padrão e permita explicitamente apenas os caminhos de comunicação necessários para limitar o impacto de um comprometimento.

Os segredos do Kubernetes são codificados em base64, e não criptografados, por padrão. Ative a criptografia em repouso para o etcd. Utilize o External Secrets Operator ou o Vault Agent Injector para obter segredos do HashiCorp Vault ou de gerenciadores de segredos na nuvem, em vez de utilizar os segredos do Kubernetes.

Os controladores de admissão interceptam as solicitações à API antes que os objetos sejam criados. O OPA/Gatekeeper aplica políticas personalizadas (por exemplo, exige rótulos específicos e bloqueia contêineres privilegiados). O Kyverno fornece política como código com uma sintaxe YAML mais simples para restrições de segurança comuns do Kubernetes.

O Falco detecta comportamento anômalo em tempo de execução usando eBPF: interpretadores de comandos iniciados em contêineres, conexões de saída inesperadas, arquivos gravados em /etc, tentativas de elevação de privilégios e execução de ferramentas de ataque conhecidas. As regras de alerta são personalizáveis em YAML.

Ative o registro de auditoria do servidor de API para registrar cada solicitação com o usuário, a ação, o recurso e a marca de data e hora. Encaminhe os registros para um SIEM a fim de detectar atividades incomuns na API: listagem de tokens de ServiceAccount, enumeração de segredos, elevação de funções e execução de kubectl em pods de produção.

Assine imagens de contêiner com Cosign (Sigstore) para garantir a integridade da cadeia de fornecimento. Os controladores de políticas (Connaisseur, Kyverno) podem exigir que apenas imagens assinadas de registros confiáveis sejam admitidas no cluster, bloqueando downloads de imagens não confiáveis.

O que uma NetworkPolicy do Kubernetes com um podSelector vazio e policyTypes Ingress/Egress realiza?

A segurança de contêineres e do Kubernetes exige proteger a cadeia de fornecimento das imagens, aplicar RBAC e os padrões de segurança de pods, implementar políticas de rede, gerenciar segredos corretamente e utilizar detecção em tempo de execução para identificar ataques que contornam os controles preventivos.