Keine Secrets in der Konfiguration.

Der Proxy ist die universelle Integration.

Wenn Ihre Workload HTTPS-Aufrufe tätigt, injiziert der Clavitor-Proxy die Anmeldedaten auf der Netzwerkschicht. Keine Codeänderungen. Keine SDKs. Keine Geheimnisse in Umgebungsvariablen, Konfigurationsdateien oder Logs. Setzen Sie HTTPS_PROXY und Ihr bestehender Code funktioniert unverändert — der Proxy löst clavitor://-Referenzen in Request-Headern auf, bevor die Anfrage das System verlässt.

$ export HTTPS_PROXY=http://localhost:1983
$ curl -H "Authorization: Bearer clavitor://Stripe API/key" \
  https://api.stripe.com/v1/charges
# Der Agent sieht niemals sk_live_... -- nur clavitor:// erscheint in den Logs

Container

Docker und Kubernetes

Docker Compose

Führen Sie den Clavitor-Proxy auf dem Host aus und leiten Sie Ihre Container dorthin um. Anmeldedaten werden transparent in ausgehende Anfragen injiziert – keine Secrets in Umgebungsvariablen, keine in Images eingebetteten Secrets.

# Auf dem Docker-Host
$ clavitor-proxy serve &

# docker-compose.yml -- Container leiten über den Proxy im Host-Modus
services:
  app:
    environment:
      - HTTPS_PROXY=http://host.docker.internal:1983
    extra_hosts:
      - "host.docker.internal:host-gateway"

Oder verwenden Sie render, um eine Konfigurationsvorlage beim Start aufzulösen:

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

Kubernetes

Erstellen Sie Secrets aus dem Vault, ohne Werte hart in Manifesten zu kodieren:

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

Für die Anmeldedaten-Injektion zur Laufzeit implementieren Sie den Proxy als Sidecar-Container in Ihrem Pod. Applikations-Container setzen HTTPS_PROXY auf den Sidecar. Anmeldedaten werden pro Anfrage aufgelöst und niemals in etcd gespeichert.

IaC

Terraform, Ansible, Pulumi

Terraform

Lösen Sie Anmeldedaten in der Provider-Umgebung vor terraform apply auf. Der AWS-Provider liest seine Anmeldedaten aus Standard-Umgebungsvariablen — Clavitor befüllt diese inline, die .tf-Datei erwähnt kein Geheimnis.

$ 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

Der provider "aws" {}-Block bleibt in Ihrem Code leer. Dasselbe Muster funktioniert für jeden Terraform-Provider, der Umgebungsvariablen für Anmeldedaten unterstützt (was auf die meisten zutrifft).

Ansible

- name: Datenbank-Passwort abrufen
  command: clavitor-cli get "Production DB" --field password
  register: db_pass
  no_log: true

- name: Applikation konfigurieren
  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

Das Token wird in jedem unten stehenden Beispiel über stdin übergeben — so bleibt es außerhalb von argv, damit es nicht in /proc/<pid>/cmdline oder in den Build-Logs erscheint.

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

Im Vault gespeicherte Schlüssel

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

Der private Schlüssel wird direkt an ssh-add übergeben. Er berührt niemals die Festplatte, erscheint nie in der Shell-Historie und wird beim Ende der Sitzung aus dem Agent gelöscht.

Altsysteme

Wenn es einen HTTP-Aufruf tätigt, funktioniert es.

Dem Proxy ist es egal, welche Sprache die Anfrage erstellt hat. COBOL, FORTRAN, Perl, Visual Basic, ein 30 Jahre alter Batch-Job — wenn der Prozess eine HTTPS-Anfrage stellt, fängt der Proxy diese ab, löst die clavitor://-Referenz auf und injiziert die echten Anmeldedaten. Keine Codeänderungen erforderlich.

Für Systeme, die keine HTTP-Aufrufe tätigen können, verwenden Sie clavitor-cli render, um eine Konfigurationsvorlage vor dem Start des Prozesses aufzulösen. Die Vorlage kann sicher an jedem Ort gespeichert werden. Die aufgelöste Ausgabe geht an stdin oder eine temporäre Datei mit eingeschränkten Berechtigungen.

# Anmeldedaten auflösen, bevor der Batch-Job startet
$ 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