Introdução ao SPIFFE e SPIRE para identidades de workload em Kubernetes

1. Fundamentos de Identidade de Workload em Ambientes Dinâmicos

1.1. Desafios de autenticação e autorização em Kubernetes

Em ambientes Kubernetes, a autenticação entre serviços enfrenta desafios únicos. Pods são efêmeros — seus nomes mudam a cada reinicialização, endereços IP são atribuídos dinamicamente e a escala horizontal cria dezenas de instâncias idênticas. Modelos tradicionais baseados em IP fixo ou nome de host simplesmente não funcionam. Além disso, gerenciar secrets compartilhados (como tokens ou senhas) em grande escala introduz riscos de vazamento e complexidade operacional.

1.2. Identidade de workload vs. identidade de usuário

Diferentemente da autenticação de usuários humanos (que envolve credenciais de longo prazo, MFA e sessões), workloads precisam de identidades programáticas, automatizadas e de curta duração. Um microsserviço de pagamento não "loga" — ele precisa provar quem é para outro serviço, como o gateway de API, sem intervenção manual.

1.3. Certificados X.509 como base criptográfica

Certificados X.509 fornecem a infraestrutura ideal: são padronizados, suportam assinatura digital, têm validade configurável e permitem renovação automática. Cada workload recebe um certificado único que pode ser verificado por qualquer outra workload no cluster, estabelecendo confiança criptográfica.

2. Visão Geral do Padrão SPIFFE

2.1. Definição e propósito

SPIFFE (Secure Production Identity Framework for Everyone) é um padrão aberto da CNCF que define como emitir e verificar identidades para workloads em ambientes dinâmicos. Seu objetivo é fornecer uma identidade universal e portátil que funcione em qualquer plataforma — Kubernetes, nomad, máquinas virtuais ou bare metal.

2.2. Componentes principais

  • SPIFFE ID: Um identificador único no formato URI que representa uma workload. Exemplo: spiffe://cluster.local/ns/default/sa/meu-servico
  • SVID (SPIFFE Verifiable Identity Document): O documento criptográfico que comprova o SPIFFE ID. Pode ser um certificado X.509 ou um token JWT.

2.3. Formato do SPIFFE ID

spiffe://<trust-domain>/<path>

O trust domain define o domínio de confiança (ex.: cluster.local), e o path identifica a workload específica, geralmente usando namespace e ServiceAccount no Kubernetes.

3. Arquitetura e Componentes do SPIRE

3.1. SPIRE Server

O SPIRE Server é a autoridade central que:
- Mantém a autoridade certificadora (CA) do trust domain
- Registra workloads e suas políticas de atestação
- Emite e assina SVIDs
- Realiza rotação automática de certificados

3.2. SPIRE Agent

O SPIRE Agent roda em cada nó do cluster e:
- Atesta a identidade do nó junto ao Server
- Escuta a Workload API via Unix socket
- Entrega SVIDs para workloads locais após atestação bem-sucedida

3.3. Workload API

A Workload API é um endpoint Unix socket (/run/spire/sockets/agent.sock) que workloads consultam para obter seus SVIDs. A API é protegida por permissões de arquivo no sistema operacional.

4. Integração do SPIRE com Kubernetes

4.1. Atestação de nó

O SPIRE Agent atesta sua identidade usando tokens do Kubernetes ou metadados do provedor de nuvem. Exemplo usando token do K8s:

Node attestation config:
  plugin: k8s_sat
  cluster: meu-cluster
  service_account_whitelist: ["spire:spire-agent"]

4.2. Atestação de workload

O SPIRE identifica workloads através de seletores — combinações de namespace, ServiceAccount, labels e annotations do pod.

4.3. Exemplo de registro

Entry ID: 1234-5678
SPIFFE ID: spiffe://cluster.local/ns/producao/sa/api-pagamentos
Parent ID: spiffe://cluster.local/spire/agent/k8s_sat/node-1
Selector: k8s:sa:api-pagamentos
Selector: k8s:ns:producao
TTL: 3600

5. Fluxo de Emissão e Rotação de SVIDs

5.1. Processo passo a passo

  1. Workload conecta ao Unix socket do SPIRE Agent
  2. Agent coleta evidências do pod (ServiceAccount, namespace)
  3. Agent envia requisição ao SPIRE Server com as evidências
  4. Server verifica contra entradas registradas
  5. Server gera certificado X.509 SVID assinado pela CA
  6. Agent entrega o SVID à workload via Workload API

5.2. Certificados de curta duração

SVIDs têm TTL configurável (padrão 1 hora). Isso minimiza o impacto de comprometimento de credenciais.

5.3. Renovação automática

O SPIRE Agent monitora a expiração dos SVIDs e renova automaticamente antes do vencimento, garantindo disponibilidade contínua.

6. Casos de Uso Práticos

6.1. Autenticação mútua (mTLS)

Dois serviços podem usar seus SVIDs para estabelecer mTLS sem compartilhar secrets:

Serviço A (spiffe://cluster.local/ns/default/sa/servico-a)
  → Apresenta certificado SVID
Serviço B (spiffe://cluster.local/ns/default/sa/servico-b)
  → Verifica certificado contra trust bundle do SPIRE
  → Conexão mTLS estabelecida

6.2. Integração com service mesh

Istio e Linkerd podem usar SPIRE como autoridade de identidade, substituindo o gerenciamento de certificados nativo do mesh.

6.3. Exemplo de pod com sidecar SPIRE Agent

apiVersion: v1
kind: Pod
metadata:
  name: app-exemplo
  labels:
    app: pagamentos
spec:
  serviceAccountName: api-pagamentos
  containers:
  - name: app
    image: minha-app:1.0
    volumeMounts:
    - name: spire-agent-socket
      mountPath: /run/spire/sockets
  - name: spire-agent
    image: spire-agent:1.8
    args: ["-config", "/run/spire/config/agent.conf"]
    volumeMounts:
    - name: spire-agent-socket
      mountPath: /run/spire/sockets
    - name: spire-config
      mountPath: /run/spire/config
  volumes:
  - name: spire-agent-socket
    emptyDir: {}
  - name: spire-config
    configMap:
      name: spire-agent-config

7. Segurança, Limitações e Boas Práticas

7.1. Segurança do SPIRE Server

  • Utilize HSM ou soluções de gerenciamento de chaves para proteger a CA
  • Faça backup regular das chaves do Server
  • Restrinja acesso à API de administração do SPIRE

7.2. Limitações conhecidas

  • Latência inicial: A primeira emissão de SVID pode levar alguns segundos
  • Dependência de DNS: O cluster precisa de DNS funcional para resolução de nomes
  • Complexidade operacional: Requer configuração cuidadosa de seletores e políticas

7.3. Boas práticas

  • Crie ServiceAccounts dedicados para cada workload
  • Monitore logs de atestação para detectar falhas
  • Configure alertas para expiração de certificados
  • Use namespaces para isolar trust domains

Referências