User's blog

Melhorando a segurança e resiliência do SPIRE com serviços gerenciados da AWS

Written by

Make.com Service User

in

O problema com credenciais estáticas em ambientes de nuvem

Em ambientes modernos de nuvem, estabelecer confiança entre workloads é um pré-requisito para proteger a comunicação máquina a máquina. Abordagens tradicionais — como chaves de API, segredos compartilhados e credenciais estáticas de contas de serviço — simplesmente não foram projetadas para a escala e a natureza efêmera dos workloads em nuvem. Isso cria uma necessidade organizacional clara: migrar de credenciais de longa duração para identidades criptográficas de curta duração.

É nesse contexto que o SPIFFE (Framework de Identidade de Produção Segura para Todos) entra em cena como componente central de estratégias de identidade de workload. O SPIFFE é um conjunto de padrões open source para identificar com segurança sistemas de software em ambientes dinâmicos e heterogêneos. Um dos problemas que ele resolve é o chamado “problema da tartaruga de baixo”: a dependência circular onde proteger uma credencial exige outra credencial — e assim por diante.

O SPIRE (Ambiente de Execução SPIFFE) é a implementação open source do SPIFFE. Ele permite que equipes experimentem o framework rapidamente, mas traz consigo considerações operacionais e de segurança importantes quando levado para produção:

  • Onde as chaves criptográficas de assinatura de identidades de workload são gerenciadas
  • Como garantir disponibilidade e resiliência do registro de identidade de workload
  • Como a Autoridade Certificadora (CA) do SPIRE se integra à PKI corporativa existente
  • Como workloads sem conectividade direta ao servidor SPIRE validam identidades
  • Como identidades de workload são entregues a ambientes serverless
  • Como autorização granular baseada em SPIFFE IDs é aplicada

A AWS publicou um guia detalhado mostrando como endereçar cada um desses pontos ao delegar as funções centrais do SPIRE para serviços gerenciados. O post é acompanhado por um repositório no GitHub com toda a infraestrutura necessária para seguir a arquitetura de referência.

Como o SPIRE funciona: conceitos essenciais

Uma implantação SPIRE é composta por pelo menos um SPIRE Server, pelo menos um SPIRE Agent e pelo menos um workload. O servidor fica em um plano de controle central e gerencia a emissão de identidades e o armazenamento de registros de workloads. Ele opera com cinco funções principais:

  • RegistrationAPI: Cria, atualiza e remove entradas que definem quais workloads têm direito a quais SPIFFE IDs, com base em seletores (namespace Kubernetes, UID Unix, etc.)
  • DataStore: Armazena os registros de identidade de workload e o status dos SVIDs emitidos
  • KeyManager: Controla como o servidor gerencia as chaves privadas usadas para assinar X.509-SVIDs e JWT-SVIDs
  • BundlePublisher: Publica o trust bundle local em um repositório. O trust bundle contém as chaves criptográficas do domínio de confiança
  • UpstreamAuthority: Define qual autoridade certificadora raiz assina o certificado CA do SPIRE

O SPIRE Agent é distribuído junto aos workloads, seja em instâncias Amazon EC2, containers Amazon ECS ou Pods do Amazon EKS. Ele expõe a Workload API, realiza atestação de nó e de workload, e pode armazenar SVIDs em destinos externos como o AWS Secrets Manager.

Após servidor e agente estarem em execução, as aplicações recuperam Documentos de Identidade Verificável SPIFFE de curta duração — seja como certificados X.509 ou JSON Web Tokens (JWTs) — usando a Workload API.

Figura 1: Arquitetura de alto nível do SPIRE — Imagem original — fonte: AWS

Usando serviços gerenciados da AWS para cada função do SPIRE

A arquitetura proposta pela AWS substitui cada componente padrão do SPIRE por um serviço gerenciado correspondente. Veja como cada integração funciona.

Figura 2: Arquitetura SPIFFE usando serviços gerenciados da AWS — Imagem original — fonte: AWS

SPIRE Key Manager com AWS KMS

O Key Manager do SPIRE controla as chaves criptográficas usadas para assinar os SVIDs. Por padrão, essas chaves ficam em memória ou em disco — o que apresenta riscos em produção. Usando o plugin AWS KMS para SPIRE, as chaves passam a ser gerenciadas pelo AWS KMS, trazendo os seguintes benefícios:

  • HSMs validados: O AWS KMS usa módulos de segurança de hardware (HSMs) validados sob FIPS 140-3 Nível 2
  • Proteção de chaves: As chaves KMS em texto simples nunca saem dos HSMs, não são gravadas em disco e são usadas apenas na memória volátil durante a operação criptográfica
  • Auditoria completa: Cada solicitação de uso das chaves é autenticada via Signature Version 4 (SigV4) e registrada no AWS CloudTrail
  • Controle de acesso granular: Use Políticas de Chave do AWS KMS para restringir quem pode usar as chaves de assinatura

O bloco de configuração abaixo indica ao SPIRE que as chaves AWS KMS devem ser usadas para assinar os SVIDs:

KeyManager "aws_kms" {
  plugin_data {
    region = "<your-region>"
    key_identifier_file = "./key_metadata"
  }
}

SPIRE DataStore com Amazon Aurora

Por padrão, o SPIRE usa um banco SQLite em memória para armazenar os registros de identidade de workload. A AWS recomenda substituir isso pelo Amazon Aurora, desacoplando o banco de dados do servidor e eliminando a carga operacional de gerenciá-lo manualmente. Os benefícios incluem alta disponibilidade com failover automático e implantações multi-AZ, backups automatizados com recuperação point-in-time, escalabilidade independente de computação e armazenamento, criptografia em repouso e em trânsito com AWS IAM, e atualizações e patches automáticos.

O stack CloudFormation provisiona um cluster Aurora PostgreSQL, um usuário de banco com autenticação via IAM e a conectividade de rede entre o servidor SPIRE e o banco. A configuração do DataStore muda de:

DataStore "sql" {
  plugin_data {
    database_type = "sqlite3"
    connection_string = "/opt/spire/data/server/datastore.sqlite3"
  }
}

Para:

DataStore "sql" {
  plugin_data {
    database_type "aws_postgres" {
      region = "<region>"
    }
    connection_string = "dbname=<dbname> user=spiffe host=<your_db_endpoint> port=<your_port>"
  }
}

Mais detalhes estão disponíveis na documentação do Plugin Datastore SQL.

Autoridade Certificadora do SPIRE com AWS Private CA

Na configuração padrão, o SPIRE gera um certificado autoassinado como CA raiz. Em produção, organizações geralmente precisam encadear essa CA à hierarquia PKI corporativa existente. Usando o plugin AWS Private Certificate Authority (AWS Private CA), o SPIRE passa a atuar como uma CA emissora que encadeia à CA raiz existente. Os benefícios são:

Importante: se o certificado CA do SPIRE for assinado por uma CA emissora, é necessário garantir que o path length dessa CA seja de pelo menos 1. O código de exemplo provisiona uma CA raiz, então isso não é um problema ao seguir o sample.

Após a implantação, a configuração do servidor SPIRE inclui o plugin UpstreamAuthority:

UpstreamAuthority "aws_pca" {
  plugin_data {
    region = "<aws_region>"
    certificate_authority_arn = "<your_pca_arn>"
    ca_signing_template_arn = "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1"
  }
}

Mais detalhes estão disponíveis na documentação do plugin AWS Private CA upstream authority.

SPIRE Bundle Publisher com Amazon S3

No SPIFFE, trust bundles são conjuntos de chaves públicas usadas pelos workloads de destino para verificar a identidade dos workloads de origem. O SPIRE Server suporta publicar esse bundle no Amazon S3. Com isso é possível:

  • Desacoplar: O acesso ao bundle deixa de depender da disponibilidade do servidor SPIRE
  • Validação contínua: Workloads de destino podem validar identidades de origem sem precisar de acesso de rede direto ao servidor SPIRE
  • Distribuição global: O bundle pode ser distribuído via Amazon CloudFront, com mais de 750 Pontos de Presença ao redor do mundo
  • Redução de carga: O tráfego de recuperação do trust bundle é descarregado do servidor SPIRE
  • Controle de versão: Versões históricas dos trust bundles podem ser mantidas com o versionamento do S3

Exemplo de configuração para este plugin:

BundlePublisher "aws_s3" {
  plugin_data {
    region = "<your_bucket_region>"
    bucket = "<your_bucket_name>"
    object_key = "<your_bundle_name"
    format = "spiffe"
  }
}

Mais detalhes na referência do Plugin S3 Bundle Publisher.

SPIRE Agent SVID Store com Secrets Manager

Em uma implementação típica do SPIRE, os SVIDs são recuperados da Workload API pelo agente SPIRE. Porém, em cenários serverless ou de container, não é viável executar o agente SPIRE — especialmente em workloads rodando no AWS Lambda ou em agentes de IA no Amazon Bedrock AgentCore Runtime.

Nesses casos, o plugin SVID store permite que o SVID seja enviado diretamente para o Secrets Manager. Um agente SPIRE ainda precisa estar rodando em algum nó para realizar a atestação de nó com o servidor SPIRE e entregar o SVID ao secrets store. O Plugin AWS Secrets Manager SVIDStore oferece:

Este plugin é configurado no agente, não no servidor SPIRE. As permissões necessárias estão documentadas no repositório GitHub do plugin. No arquivo agent.conf do código de exemplo, a configuração é:

SVIDStore "aws_secretsmanager" {
  plugin_data {
    region = "<your_region>"
  }
}

Para que o SVID de um workload específico seja enviado ao Secrets Manager, os parâmetros storeSVID e selector precisam ser adicionados ao criar a entrada no registro de workload. Em um ambiente Kubernetes, o comando fica assim:

kubectl exec -n spire spire-server-<postfix>-- \
  /opt/spire/bin/spire-server entry create \
  -spiffeID spiffe://example.org/<workload_name> \
  -parentID spiffe://example.org/ns/spire/sa/spire-agent \
  -selector aws_secretsmanager:secretname:<workload_name> \
  -storeSVID

Controle de acesso granular com Amazon Verified Permissions

Todos os serviços gerenciados mencionados até aqui tratam da criação e distribuição de SVIDs e trust bundles. Mas um dos grandes diferenciais do SPIFFE é permitir que donos de recursos protejam seus recursos com autorização granular. O Amazon Verified Permissions é o serviço gerenciado que atende a essa necessidade no contexto de implementações SPIFFE/SPIRE.

Com o Verified Permissions é possível:

  • Definir políticas declarativas: Usando a linguagem de políticas Cedar, que oferece regras de controle de acesso legíveis por humanos
  • Centralizar o gerenciamento de políticas: Separando a lógica de autorização do código da aplicação, com suporte a verificação formal e benefícios de performance do Cedar
  • Tomar decisões em tempo real: Avaliando requisições de autorização com base em identidade do usuário, identidade do workload (SPIFFE ID), atributos do recurso e informações contextuais
  • Integrar com provedores de identidade: Com suporte a provedores OpenID Connect (OIDC), habilitando validação de tokens JWT, incluindo JWT-SVIDs

Para usar o Verified Permissions, são necessários um policy store, uma fonte de identidade e políticas de autorização. O código de exemplo cria o policy store e configura a infraestrutura para que o SPIRE atue como fonte de identidade.

A política abaixo proíbe um workload específico de executar qualquer ação:

forbid(
  principal,
  action,
  resource
) when {
  context has sub &&
  context.sub like "spiffe://example.org/forbidden-workload/*"
};

E esta permite que um workload específico execute ações:

permit(
  principal,
  action,
  resource
) when {
  context has sub &&
  context.sub like "spiffe://example.org/allowed-workload/*"
};

Conclusão

A AWS demonstrou como organizações podem aprimorar suas implantações SPIRE substituindo implementações padrão por serviços gerenciados. As integrações cobrem AWS KMS para assinatura de SVIDs, Amazon Aurora para operações de datastore gerenciado, AWS Private CA para raiz de confiança, Amazon S3 e CloudFront para distribuição global de trust bundles, AWS Secrets Manager para armazenamento de SVIDs e Amazon Verified Permissions para autorização granular.

Ao adotar essas integrações, as organizações conseguem melhorar a postura de segurança, reduzir a complexidade operacional e aumentar a resiliência de suas implantações SPIRE. Para quem quer aprender mais, a AWS disponibiliza o repositório GitHub do SPIRE on AWS e o Workshop SPIFFE e SPIRE na AWS para aprendizado prático.

Fonte

Improving SPIRE security and resiliency with AWS managed services (https://aws.amazon.com/blogs/security/improving-spire-security-and-resiliency-with-aws-managed-services/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts