Explica por que os SVIDs de curta duração do SPIFFE/SPIRE ainda dependem da integridade do nó, o que um teste de falsificação de cgroup em laboratório demonstrou e quais controles do Kubernetes podem limitar o impacto.
O SPIFFE fornece aos serviços documentos de identidade criptográfica de curta duração chamados SVIDs. As cargas de trabalho podem usá-los para estabelecer conexões TLS ou assinar e verificar JWTs. A visão geral oficial do SPIFFE define esse modelo.
Onde a decisão sobre a identidade é tomada
O SPIRE realiza a atestação de nós e cargas de trabalho antes de emitir SVIDs. Durante a atestação da carga de trabalho, o agente SPIRE determina as propriedades de um processo a partir de fontes locais, como o kernel do sistema operacional ou um kubelet no mesmo nó. Em seguida, compara essas propriedades com as condições dos seletores em uma entrada de registro; quando há correspondência, ela determina qual SPIFFE ID o processo recebe. A documentação de conceitos do SPIRE descreve esse mecanismo.
O alcance do achado em laboratório
Nesse modelo, a validade criptográfica de um SVID e sua emissão para o processo pretendido são questões distintas. A pesquisa em laboratório da Unit 42 mostrou que um invasor com acesso root prévio a um nó do Kubernetes poderia falsificar informações de cgroup do Linux, enganar o agente SPIRE e obter um SVID válido pertencente a outra carga de trabalho no mesmo nó. O fluxo técnico está documentado na pesquisa da Unit 42.
A Unit 42 declara explicitamente que não observou essa técnica em ataques reais. Portanto, o achado não é evidência de exploração ativa; ele descreve um risco pós-exploração que surge depois que o acesso root quebra a confiança no nó.
Um modelo de defesa para o risco associado ao nó
Para planejar a defesa, o comprometimento de um nó deve ser tratado como o comprometimento de todas as identidades de cargas de trabalho com escopo nesse nó. As orientações da Unit 42 incluem restringir contêineres privilegiados e o acesso direto ao host, além de reduzir a dependência de seletores fracos ou fáceis de falsificar. O escopo relevante é o nó comprometido, não automaticamente o cluster inteiro.
Reduza os privilégios de pods e nós
O perfil Restricted dos Pod Security Standards do Kubernetes exige que pods privilegiados sejam proibidos, que a elevação de privilégios seja bloqueada e que os contêineres sejam executados como usuários não root. A lista de verificação de segurança oficial também informa que o seccomp pode reduzir a superfície de chamadas de sistema do kernel do Linux disponível dentro dos contêineres. Os detalhes estão nos Pod Security Standards e na lista de verificação de segurança do Kubernetes.
Trate os seletores como parte do limite de confiança
Os seletores não são apenas detalhes de correspondência: eles determinam quais propriedades locais são consideradas na decisão de atestação. Por isso, uma revisão deve avaliar quais dados do sistema operacional ou do kubelet fornecem as informações para cada condição e se o acesso root poderia facilitar a falsificação desses dados. O objetivo é usar seletores que distingam as cargas de trabalho de forma específica, em vez de condições amplas ou fracas.
Separe níveis de sensibilidade e credenciais adicionais
O Kubernetes também recomenda colocar cargas de trabalho com diferentes níveis de sensibilidade em nós separados e não montar tokens de contas de serviço em pods que não precisam deles. Os dois controles são descritos na lista de verificação de segurança oficial.
A separação de nós busca dificultar o avanço direto para aplicações mais sensíveis após a fuga de um contêiner. Não montar um token de conta de serviço desnecessário também impede que uma credencial adicional, distinta do SVID, esteja presente dentro do pod.
Uma sequência prática de revisão
Esse limite de confiança pode ser traduzido em uma breve sequência de revisão que considere, em conjunto, a configuração e a distribuição das cargas de trabalho:
Escopo das identidades: Quais SPIFFE IDs estão no escopo de cada nó e quais níveis de sensibilidade compartilham esse nó?
Dados de entrada da atestação: Quais dados do sistema operacional ou do kubelet alimentam os seletores, e o acesso root poderia permitir a falsificação desses dados?
Privilégios no nó: Quais pods são privilegiados, podem acessar o host, permitem a elevação de privilégios ou são executados como root?
Credenciais adicionais: Quais pods recebem tokens de contas de serviço mesmo sem precisar deles?
A conclusão não é que os SVIDs não tenham valor. Suas garantias de identidade criptográfica devem ser avaliadas em conjunto com a integridade do nó onde ocorre a atestação. Um modelo resiliente combina identidade de curta duração para cargas de trabalho com reforço de segurança dos pods, condições específicas nos seletores, separação de nós por sensibilidade e remoção de credenciais desnecessárias.
