Zéro secret en configuration. Zéro secret dans les journaux.

Le proxy est l'intégration universelle.

Si votre charge de travail effectue des appels HTTPS, le proxy Clavitor injecte les identifiants au niveau réseau. Aucune modification de code. Aucun SDK. Aucun secret dans les variables d'environnement, les fichiers de configuration ou les journaux. Définissez HTTPS_PROXY et votre code existant fonctionne sans modification — le proxy résout les références clavitor:// dans les en-têtes de requête avant que la requête ne quitte la machine.

$ 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

Conteneurs

Docker et Kubernetes

Docker Compose

Exécutez le proxy Clavitor sur l'hôte et pointez vos conteneurs vers celui-ci. Les identifiants sont injectés de manière transparente dans les requêtes sortantes — aucun secret dans les variables d'environnement, aucun secret intégré dans les images.

# 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 utilisez render pour résoudre un modèle de configuration au démarrage :

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

Kubernetes

Créez des secrets à partir du coffre-fort sans coder en dur les valeurs dans les manifestes :

$ 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)"

Pour l'injection d'identifiants à l'exécution, déployez le proxy en tant que conteneur sidecar dans votre pod. Les conteneurs d'application définissent HTTPS_PROXY vers le sidecar. Les identifiants sont résolus par requête, jamais stockés dans etcd.

IaC

Terraform, Ansible, Pulumi

Terraform

Résolvez les identifiants dans l'environnement du fournisseur avant terraform apply. Le fournisseur AWS lit ses identifiants à partir des variables d'environnement standard — Clavitor les remplit en ligne, le fichier .tf ne mentionne aucun secret.

$ 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

Le bloc provider "aws" {} reste vide dans votre code. Le même modèle fonctionne pour tout fournisseur Terraform qui prend en charge les identifiants via des variables d'environnement (ce qui est le cas de la plupart d'entre eux).

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

Le jeton est transmis sur stdin dans chaque exemple ci-dessous — le gardant hors de argv afin qu'il n'apparaisse pas dans /proc/<pid>/cmdline ou les journaux 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

Clés stockées dans le coffre-fort

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

La clé privée est transmise directement à ssh-add. Elle ne touche jamais le disque, n'apparaît jamais dans l'historique du shell, et est effacée de l'agent à la fin de la session.

Systèmes hérités

Si cela effectue un appel HTTP, cela fonctionne.

Le proxy ne se soucie pas du langage qui a effectué la requête. COBOL, FORTRAN, Perl, Visual Basic, un job batch vieux de 30 ans — si le processus effectue une requête HTTPS, le proxy l'intercepte, résout la référence clavitor://, et injecte le véritable identifiant. Aucune modification de code requise.

Pour les systèmes qui ne peuvent pas effectuer d'appels HTTP, utilisez clavitor-cli render pour résoudre un modèle de configuration avant le démarrage du processus. Le modèle peut être stocké en toute sécurité n'importe où. La sortie résolue va vers stdin ou un fichier temporaire avec des permissions restreintes.

# 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