No ecossistema de infraestrutura cloud, a segurança e a performance muitas vezes caminham em direções opostas. O Kubernetes v1.36 trouxe um marco importante para quem opera em ambientes Linux com SELinux em modo enforcing: a transição do SELinuxMount para um comportamento que, em breve, será o padrão (previsto para o v1.37).
Historicamente, o kubelet delegava a tarefa de aplicar labels do SELinux ao container runtime, que realizava uma verificação recursiva em todos os arquivos de um volume. Em volumes remotos ou com um grande número de inodes, essa operação gera latência significativa no deployment de um Pod. A nova abordagem, que utiliza -o context=<label> na montagem, resolve esse gargalo de performance, mas impõe restrições rígidas que equipes de engenharia precisam mapear antes de uma atualização de versão.
O que muda na prática para sua operação
A mudança técnica é uma melhoria substancial de eficiência operacional: ao montar o volume diretamente com a label correta, eliminamos a necessidade de percorrer todo o sistema de arquivos. Contudo, essa mudança altera os cenários de compartilhamento de volumes. Em versões anteriores, era comum permitir que um Pod privilegiado e outro não privilegiado acessassem o mesmo volume. Com a nova implementação, cenários que dependiam dessa flexibilidade de labels do SELinux falharão, deixando o Pod parado em ContainerCreating.
Para times de SecOps e gestores de infra, o ponto de atenção é o selinux-warning-controller. Recomendamos fortemente a ativação deste controller no kube-controller-manager (usando --controllers=*,selinux-warning-controller). Ele é a ferramenta mais eficaz para identificar potenciais conflitos de labels via métrica selinux_warning_controller_selinux_volume_conflict antes que eles se tornem incidentes de indisponibilidade em produção.
Estratégia de transição para empresas brasileiras
Nossa análise sugere uma abordagem consultiva em três etapas:
- Auditoria: Ative o controller de aviso no controle de plano e monitore os logs de intenção de conflito.
- Mitigação: Utilize o novo campo
spec.securityContext.seLinuxChangePolicy. Para aplicações legadas que não podem ser rearquitetadas, a definição deRecursivemanterá o comportamento antigo (e seguro, embora mais lento). - Padronização: Aproveite o momento para avaliar se a carga de trabalho realmente necessita de privilégios elevados. O uso de
MutatingAdmissionPoliciesou ferramentas como Kyverno/Gatekeeper pode automatizar essa transição, garantindo conformidade sem intervenção manual em todo deployment novo.
Para empresas que dependem de alta disponibilidade e estabilidade, tratar essas mudanças como parte da rotina de upgrade do Kubernetes é a diferença entre um ambiente resiliente e uma manutenção não planejada.
Artigo originalmente publicado em Kubernetes Blog.
