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.
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.
Cada consumidor não humano é uma Application com:
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.
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).
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.
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.
Consulte também Console > A2A e a automação Change Secret em Automations.
Atualizado
Isto foi útil?
Isto foi útil?
