Para CI/CD
Secret Manager para CI/CD
Pipelines CI/CD sao o vetor de ataque favorito em supply chain compromise: tokens longos vivem em variaveis do runner, gerentes de pacote pegam credenciais expostas em logs e plugins maliciosos exfiltram secrets. A solução nao eh esconder melhor — eh eliminar tokens longos via workload identity.
Por que CipherVault para CI/CD
- Plugins oficiais: GitHub Actions, GitLab CI, Jenkins, CircleCI, Bamboo
- Workload identity via OIDC JWT-SVID (sem token longo no runner)
- TTL ≤30min: credencial expira antes do próximo job
- Audit por commit SHA e job ID (rastreabilidade total)
- Compatibilidade com Tekton, Argo Workflows e Drone
- Suporte a ephemeral runners (Kubernetes, EC2 spot)
Caso de uso típico
Pipeline GitHub Actions que precisa de acesso a npm registry privado, AWS para deploy, Snyk para scan e Slack para notificação — tudo sem secrets persistentes.
Como fica na prática
CI/CD
# .github/workflows/deploy.yml
name: Deploy
on: push
permissions:
id-token: write # necessário para OIDC
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: ciphervault/auth-action@v1
with:
endpoint: ${{ vars.CV_ENDPOINT }}
role: ci-deploy-prod
# sem secrets: a action exchange OIDC token por credenciais CV
- run: |
npm ci --registry=$CV_NPM_REGISTRY
aws deploy create-deployment ...
# credenciais sao tmpfs, expiram em 30minPerguntas frequentes — CI/CD
Sim. Para runners self-hosted no Kubernetes, recomendamos combinar com workload identity SPIFFE. Para VMs persistentes, o OIDC do CI continua funcionando.