Accedi Gratis per sempre Iniziare

Infrastruttura

Nessun segreto nella configurazione.
Nessun segreto nei log.

Ogni piattaforma, ogni orchestrator, ogni runner CI. Il proxy funziona con qualsiasi cosa effettui chiamate HTTP. La CLI funziona con qualsiasi cosa possa eseguire comandi shell. Se il Suo sistema è più vecchio della Sua carriera, funziona comunque.

Il proxy è l'integrazione universale.

Se il Suo workload effettua chiamate HTTPS, il proxy Clavitor inietta le credenziali a livello di rete. Nessuna modifica al codice. Nessun SDK. Nessun segreto nelle variabili d'ambiente, nei file di configurazione o nei log. Imposti HTTPS_PROXY e il Suo codice esistente funzionerà invariato — il proxy risolve i riferimenti clavitor:// nelle intestazioni delle richieste prima che la richiesta lasci la macchina.

$ 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

Container

Docker e Kubernetes

Docker Compose

Esegua il proxy Clavitor sull'host e indirizzi i Suoi container verso di esso. Le credenziali vengono iniettate in modo trasparente nelle richieste in uscita — nessun segreto nelle variabili d'ambiente, nessun segreto incorporato nelle immagini.

# 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"

Oppure utilizzi render per risolvere un template di configurazione all'avvio:

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

Kubernetes

Crei segreti dalla cassaforte senza codificare valori nei manifest:

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

Per l'iniezione di credenziali a runtime, distribuisca il proxy come container sidecar nel Suo pod. I container dell'applicazione impostano HTTPS_PROXY verso il sidecar. Le credenziali vengono risolte per richiesta, mai memorizzate in etcd.

IaC

Terraform, Ansible, Pulumi

Terraform

Risolva le credenziali nell'ambiente del provider prima di terraform apply. Il provider AWS legge le Sue credenziali dalle variabili d'ambiente standard — Clavitor le popola inline, il file .tf non menziona alcun segreto.

$ 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

Il blocco provider "aws" {} rimane vuoto nel Suo codice. Lo stesso modello funziona per qualsiasi provider Terraform che supporti credenziali tramite variabili d'ambiente (che sono la maggior parte).

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

Il token viene passato su stdin in ogni esempio seguente — mantenendolo fuori da argv in modo che non appaia in /proc/<pid>/cmdline o nei log di 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

Chiavi archiviate nella cassaforte

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

La chiave privata viene passata direttamente a ssh-add. Non tocca mai il disco, non appare mai nella cronologia della shell e viene rimossa dall'agente al termine della sessione.

Sistemi legacy

Se effettua una chiamata HTTP, funziona.

Al proxy non importa quale linguaggio abbia effettuato la richiesta. COBOL, FORTRAN, Perl, Visual Basic, un processo batch di 30 anni — se il processo effettua una richiesta HTTPS, il proxy la intercetta, risolve il riferimento clavitor:// e inietta la credenziale reale. Nessuna modifica al codice richiesta.

Per i sistemi che non possono effettuare chiamate HTTP, utilizzi clavitor-cli render per risolvere un template di configurazione prima dell'avvio del processo. Il template può essere archiviato in modo sicuro ovunque. L'output risolto viene inviato a stdin o a un file temporaneo con permessi limitati.

# 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

Il modello è sempre lo stesso.

CLI per script e pipeline. Proxy per workload HTTP. Render per file di configurazione. Ogni segreto risolto a runtime, mai archiviato.