Se você gerencia infraestrutura Kubernetes e mantém ou utiliza CSI drivers que dependem de Service Account Tokens para autenticação, a chegada do Kubernetes v1.35 traz uma evolução crítica em termos de SecOps e conformidade.
Historicamente, desde a introdução do recurso TokenRequests, os tokens solicitados por CSI drivers eram transmitidos através do campo volume_context. Embora funcional, essa abordagem apresentava uma falha de design sob a ótica de segurança: o volume_context não foi concebido para dados sensíveis. Na prática, isso resultou em incidentes onde tokens foram registrados indevidamente em logs de depuração, expondo vetores de ataque.
A v1.35 introduz uma solução em beta: o CSI Driver Opt-in for Service Account Tokens via Secrets field. Essa mudança permite que os tokens trafeguem pelo campo secrets no NodePublishVolumeRequest, o local tecnicamente apropriado segundo a especificação CSI para informações sigilosas.
O Problema do Modelo Atual
No modelo anterior, ao configurar o campo TokenRequests na spec do CSIDriver, os tokens eram injetados no mapa de atributos do volume com a chave csi.storage.k8s.io/serviceAccount.tokens.
As consequências práticas para times de engenharia no Brasil, especialmente em setores regulados (como FinTechs), eram consideráveis:
- Vazamento de Credenciais: Ferramentas como o
protosanitizer, amplamente usadas em CSI drivers, não tratam o contexto do volume como sensível. Isso levou a vulnerabilidades reais (CVE-2023-2878 e CVE-2024-3744) onde tokens SA vazaram em logs de gRPC. - Inconsistência Operacional: Cada mantenedor de driver precisava implementar sua própria lógica de sanitização, aumentando a complexidade do código e a superfície de erro.
Ao migrar para o campo secrets, o Kubernetes passa a tratar esses tokens com as mesmas garantias de expurgo de logs aplicadas a senhas e chaves de criptografia.
Como funciona o mecanismo de Opt-in
A comunidade Kubernetes optou por um modelo de transição suave. Em vez de uma mudança disruptiva, os CSI drivers agora podem sinalizar ao orchestrator como desejam receber esses dados.
No manifesto do CSIDriver, um novo campo foi adicionado:
# Exemplo de configuração estratégica
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: exemplo-csi-driver
spec:
tokenRequests:
- audience: "nuvemonline.com.br"
expirationSeconds: 3600
# Novo campo para habilitar a entrega via secrets
serviceAccountTokenInSecrets: true # O padrão é false para manter retrocompatibilidade
- Se
false: O comportamento permanece o antigo (viaVolumeContext). - Se
true: O Kubernetes move o token exclusivamente para o campoSecrets.
Guia de Implementação para Engenheiros: Lógica de Fallback
Para garantir que seu driver não quebre durante o ciclo de vida do cluster (especialmente em cenários de multi-cloud ou upgrade progressivo), a recomendação é implementar uma lógica de busca dupla. Isso permite que o driver funcione tanto em versões anteriores do Kubernetes quanto na v1.35 com o novo recurso habilitado.
(Nota: O diagrama original ilustra o fluxo de decisão do token entre Secrets e VolumeContext)
Exemplo de implementação em Go:
const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"
func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
// 1. Tenta buscar no campo secrets (novo padrão de segurança)
if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
return tokens, nil
}
// 2. Fallback para volume context (compatibilidade com clusters legados)
if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
return tokens, nil
}
return "", fmt.Errorf("tokens de service account não encontrados")
}
Sequência de Rollout Segura
Para tomadores de decisão e gestores de infraestrutura, a ordem dos fatores altera o produto. Um erro na sequência de atualização pode causar falhas em cascata no deployment de workloads que dependem de armazenamento:
- Atualização do Binário do Driver: Primeiro, faça o deploy da versão do driver que contém a lógica de fallback acima.
- Upgrade do Cluster: Atualize o
kube-apiservere okubeletpara v1.35. - Deploy do DaemonSet: Certifique-se de que todos os nós já rodam a nova versão do driver.
- Ativação do Flag: Altere o objeto
CSIDriverparaserviceAccountTokenInSecrets: true.
Considerações Estratégicas
Esta atualização não é apenas uma mudança de sintaxe; é um movimento em direção ao "Secure by Default" (seguro por padrão). Para empresas brasileiras que buscam selos de conformidade como LGPD ou certificações ISO de segurança da informação, a adoção dessa funcionalidade reduz drasticamente o risco de exposição de identidade de workload.
Ao utilizar o campo secrets nativo do CSI, o ecossistema de ferramentas de observabilidade e logs já saberá, automaticamente, o que ocultar, reduzindo a carga cognitiva do time de plataforma.
Artigo originalmente publicado por Anish Ramasekar (Microsoft) em Kubernetes Blog.
