APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um processo num container continua a usar o kernel do ambiente que o executa. As camadas de proteção têm funções diferentes: capabilities limitam classes de privilégios, seccomp filtra syscalls e AppArmor pode aplicar regras de acesso associadas ao processo. Não confundas esses mecanismos com RBAC da API. Quando surge EPERM após uma mudança de perfil, correlaciona a chamada, o perfil efetivo e a necessidade funcional. Abrir todos os syscalls pode esconder o sintoma enquanto remove a proteção. O diagnóstico deve produzir uma alteração mínima justificável e um teste do comportamento permitido e do comportamento que deve continuar bloqueado.
Aplicação guiada
Perfis Localhost acrescentam uma dependência operacional: têm de existir no node onde o Pod arranca. Num cluster com expansão automática, copiar um ficheiro manualmente para dois nodes não prepara os próximos. Inclui distribuição, versão e validação dos perfis no provisionamento. Da mesma forma, a remoção de serviços remotos desnecessários precisa de inventário de consumidores e recuperação. Num batch com prazo apertado, podes usar capacidade já preparada enquanto corriges o processo, se a capacidade for suficiente e a decisão estiver aprovada. Não transformes privileged numa correção universal. Documenta quem mantém o perfil, como se testa numa atualização de runtime e como se identifica drift antes de receber tráfego.
Se apenas os nodes novos falham com perfil inexistente, trata o provisionamento antes de alterar o código da aplicação.
Armadilhas comuns
Perfil no Git como perfil instalado; privileged como ajuste neutro; RBAC como controlo de syscalls; correção manual não repetível.
Tópicos relacionados: Admissão e proteção dos workloads · Segredos, cifragem e recuperação
O controlo precisa de estar presente, aplicado e mantido em todos os nodes elegíveis.
Referência: Linux kernel security constraints · Kubernetes v1.35; current six-domain CKS outline