Entrar Obtenha gratuitamente para sempre Comece

Infraestrutura

Zero segredos em configurações. Zero segredos em logs.

Todas as plataformas, todos os orquestradores, todos os runners de CI. O proxy funciona com qualquer coisa que faça chamadas HTTP. O CLI funciona com qualquer coisa que possa executar comandos no shell. Se o seu sistema for mais antigo que a sua carreira, ele ainda funciona.

O proxy é a integração universal.

Se sua carga de trabalho fizer chamadas HTTPS, o proxy Clavitor injetará credenciais na camada de rede. Sem alterações de código. Sem SDKs. Sem segredos em variáveis de ambiente, arquivos de configuração ou logs. Configure HTTPS_PROXY e seu código existente funcionará sem alterações — o proxy resolve referências clavitor:// nos cabeçalhos de requisição antes que a requisição saia da máquina.

$ export HTTPS_PROXY=http://localhost:1983
$ curl -H "Authorization: Bearer clavitor://Stripe API/key" \
  https://api.stripe.com/v1/charges
# The agent never sees sk_live_... — only clavitor:// appears in logs

Contêineres

Docker e Kubernetes

Docker Compose

Execute o proxy Clavitor no host e aponte seus contêineres para ele. As credenciais são injetadas transparentemente em requisições de saída — sem segredos em variáveis de ambiente, sem segredos embutidos em imagens.

# On the Docker host
$ clavitor-proxy serve &
# docker-compose.yml — containers route through the host-mode proxy
services:
  app:
    environment:
      - HTTPS_PROXY=http://host.docker.internal:1983
    extra_hosts:
      - "host.docker.internal:host-gateway"

Ou use render para resolver um template de configuração na inicialização:

$ clavitor-cli render app.config.template.yml | docker compose -f - up

Kubernetes

Crie segredos do cofre sem codificar valores em manifestos:

$ kubectl create secret generic app-secrets \
  --from-literal=db-pass="$(clavitor-cli get 'Production DB' --field password)" \
  --from-literal=api-key="$(clavitor-cli get 'Stripe API' --field key)"

Para injeção de credenciais em tempo de execução, implante o proxy como um contêiner sidecar no seu pod. Contêineres de aplicação configuram HTTPS_PROXY para o sidecar. As credenciais são resolvidas por requisição, nunca armazenadas em etcd.

IaC

Terraform, Ansible, Pulumi

Terraform

Resolva credenciais no ambiente do provedor antes do terraform apply. O provedor AWS lê suas credenciais de variáveis de ambiente padrão — Clavitor as popula inline, o arquivo .tf não menciona nenhum segredo.

$ export AWS_ACCESS_KEY_ID=$(clavitor-cli get "AWS Root" --field access_key_id)
$ export AWS_SECRET_ACCESS_KEY=$(clavitor-cli get "AWS Root" --field secret_key)
$ terraform apply

O bloco provider "aws" {} permanece vazio no seu código. O mesmo padrão funciona para qualquer provedor Terraform que suporte credenciais via variáveis de ambiente (que é a maioria deles).

Ansible

- name: Get database password
  command: clavitor-cli get "Production DB" --field password
  register: db_pass
  no_log: true

- name: Configure app
  template:
    src: app.conf.j2
  vars:
    db_password: "{{ db_pass.stdout }}"

Pulumi

import { execSync } from 'child_process';
const dbPass = execSync('clavitor-cli get "Production DB" --field password').toString().trim();
new aws.rds.Instance("db", { masterPassword: new pulumi.secret(dbPass) });

CI/CD

GitHub Actions, GitLab CI, Jenkins

O token é enviado via stdin em todos os exemplos abaixo — mantendo-o fora de argv para que não apareça em /proc/<pid>/cmdline ou logs de build.

GitHub Actions

- name: Deploy
  env:
    CLAVITOR_TOKEN: ${{ secrets.CLAVITOR_TOKEN }}
  run: |
    echo "$CLAVITOR_TOKEN" | clavitor-cli init
    kubectl create secret generic app-secrets \
      --from-literal=api-key="$(clavitor-cli get 'Deploy Token' --field key)" \
      --dry-run=client -o yaml | kubectl apply -f -

GitLab CI

deploy:
  script:
    - echo "$CLAVITOR_TOKEN" | clavitor-cli init
    - clavitor-cli get "Deploy Key" --field private_key | ssh-add -
    - ssh deploy@production "systemctl restart app"

Jenkins

pipeline {
  stages {
    stage('Deploy') {
      steps {
        sh 'echo "$CLAVITOR_TOKEN" | clavitor-cli init'
        sh 'clavitor-cli get "Deploy Key" --field private_key | ssh-add -'
        sh 'ssh deploy@production "systemctl restart app"'
      }
    }
  }
}

SSH

Chaves armazenadas no cofre

$ clavitor-cli get "Deploy Key" --field private_key | ssh-add -
$ ssh deploy@production

A chave privada é enviada diretamente para ssh-add. Ela nunca toca o disco, nunca aparece no histórico do shell e é limpa do agente quando a sessão termina.

Sistemas legados

Se fizer uma chamada HTTP, funciona.

O proxy não se importa com a linguagem que fez a requisição. COBOL, FORTRAN, Perl, Visual Basic, um job em lote de 30 anos — se o processo fizer uma requisição HTTPS, o proxy a intercepta, resolve a referência clavitor:// e injeta a credencial real. Nenhuma alteração de código é necessária.

Para sistemas que não podem fazer chamadas HTTP, use clavitor-cli render para resolver um template de configuração antes que o processo inicie. O template é seguro para armazenar em qualquer lugar. A saída resolvida vai para stdin ou um arquivo temporário com permissões restritas.

# Resolve credentials before the batch job starts
$ clavitor-cli render db-connect.template.cfg > /tmp/db-connect.cfg
$ chmod 600 /tmp/db-connect.cfg
$ /opt/legacy/batch-job --config /tmp/db-connect.cfg
$ rm /tmp/db-connect.cfg

O padrão é sempre o mesmo.

CLI para scripts e pipelines. Proxy para cargas de trabalho HTTP. Render para arquivos de configuração. Todos os segredos resolvidos em tempo de execução, nunca armazenados.