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.