Secrets para A2A (Vault KV + Kubernetes)

Entrega de segredos para comunicação Application-to-Application (A2A) no DataDike PAM: API compatível com HashiCorp Vault KV v2, autenticação por AppID (token + IP de origem) e autenticação nativa de

O módulo Secrets / A2A do DataDike PAM resolve o problema de credenciais embutidas em código (hardcoded) permitindo que aplicações, scripts, scanners de vulnerabilidade e pipelines busquem o segredo no cofre no momento do uso, de forma autenticada e auditada em vez de guardar senhas em arquivos de configuração, variáveis de ambiente ou no código-fonte.

É gerenciado no console em Console > A2A (páginas Applications e Kubernetes).

A2A (Application-to-Application) é a autenticação entre sistemas sem intervenção humana uma aplicação que lê uma senha de banco, um scanner que precisa de credencial para autenticar no alvo, um job de CI que consome uma API.

Como funciona

O DataDike PAM expõe uma API compatível com o HashiCorp Vault KV v2. Qualquer ferramenta que já fale com o Vault (Tenable, Qualys, scripts, SDKs do Vault) consome os segredos do cofre do PAM sem alteração apontando para o endpoint do PAM.

A credencial entregue é sempre a versão viva guardada no cofre do PAM (a mesma que é rotacionada pelas automações de troca de senha), então o consumidor nunca guarda uma cópia estática.

Identidades de aplicação (AppID)

Cada consumidor não humano é uma Application com:

Atributo	Função
Token	Segredo de autenticação da aplicação (estilo AppRole/token do Vault).
IP / CIDR de origem	Restringe de quais redes o token pode ser usado.
Escopo	Quais ativos/contas a aplicação pode ler.
Auditoria	Toda recuperação de segredo é registrada (quem, quando, de onde).

A revogação é imediata: desativar a Application (ou rotacionar seu token) invalida o acesso.

Autenticação nativa de Kubernetes

Para cargas em Kubernetes/OpenShift, o PAM aceita o JWT da ServiceAccount do pod como prova de identidade (mesmo modelo do auth method kubernetes do Vault): o pod apresenta seu token de ServiceAccount, o PAM valida contra o JWKS do cluster e devolve o segredo. Isso funciona com o Vault Agent Injector e o Secrets Store CSI Driver oficiais apontados para o endpoint do PAM sem sidecar proprietário.

Configuração na página Console > A2A > Kubernetes (host da API do cluster + JWKS/CA).

Casos de uso típicos

• Scanners de vulnerabilidade (Tenable, Qualys) buscam a credencial viva do alvo no momento do scan, em vez de guardar senhas no scanner.

• Pipelines / scripts DevOps leem segredos via a API Vault KV no deploy.

• Cargas em Kubernetes recebem segredos via ServiceAccount JWT.

Escopo atual e limites

O módulo entrega segredos sob demanda (API Vault KV v2 + autenticação K8s). Ele não inclui, nesta versão: varredura de repositórios Git/CI-CD em busca de segredos hardcoded, SDKs proprietários por linguagem, injeção por sidecar/CSI proprietário, nem replicação para AWS Secrets Manager / Azure Key Vault / GCP. A rotação de credenciais é feita pelas automações nativas de troca de senha (Accounts > Automations > Change Secret), e o segredo entregue por esta API é sempre a versão corrente do cofre.

Segurança e criptografia dos segredos

Os segredos gerenciados pelo módulo A2A são protegidos por criptografia em todo o ciclo de vida, em repouso, em trânsito e durante o consumo pelas aplicações de modo que nunca fiquem persistidos em texto claro.

Criptografia em repouso (no cofre)

Todo segredo é armazenado no cofre de forma criptografada com AES‑256. Em nenhum momento o valor do segredo é gravado em texto claro no banco de dados ou no sistema de arquivos da solução. As chaves de criptografia são gerenciadas pela própria plataforma e segregadas dos dados cifrados, seguindo o modelo de proteção do cofre de senhas.

Criptografia em trânsito

A recuperação de segredos pela API (compatível com HashiCorp Vault) ocorre exclusivamente sobre canais TLS, garantindo que o segredo não trafegue em texto claro pela rede entre a aplicação consumidora e a solução.

Proteção dentro dos contêineres de aplicação

As cargas em contêineres (Docker/Kubernetes) não armazenam o segredo de forma estática em imagem, variável de ambiente persistida, arquivo de configuração ou código-fonte. O segredo é obtido sob demanda, em tempo de execução, por meio da API assinada, e mantido apenas em memória pelo tempo necessário à operação não sendo gravado em texto claro em disco dentro do contêiner. A autenticação da carga é feita por identidade de aplicação (AppID/token) ou por JWT de ServiceAccount do Kubernetes, e cada recuperação é registrada em auditoria.

Não exposição em texto claro

A visualização do valor de um segredo pela console é controlada e, quando permitida, exige confirmação adicional de MFA, separada do login. Para as aplicações, o consumo é feito pela API sem exibição do valor em tela, preservando o segredo contra visualização indevida.

Rotação e revogação

Como o valor entregue é sempre a versão viva guardada no cofre, a rotação de uma credencial passa a valer imediatamente para os próximos consumos, e o acesso de uma aplicação pode ser revogado a qualquer momento, invalidando o segredo/identidade utilizados por ela.

Consulte também Console > A2A e a automação Change Secret em Automations.