配置中零机密。
日志中零机密。

代理是通用的集成方式。

如果您的工作负载发起 HTTPS 调用，Clavitor 代理会在网络层注入凭据。无需更改代码。无需 SDK。环境变量、配置文件或日志中不会出现任何机密。设置 HTTPS_PROXY，您的现有代码即可无需修改直接运行——代理会在请求离开本机前解析请求标头中的 clavitor:// 引用。

$ 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

容器

Docker 和 Kubernetes

Docker Compose

在主机上运行 Clavitor 代理，并将您的容器指向该代理。凭据会透明地注入到出站请求中——环境变量中不包含任何机密，镜像中也不嵌入任何机密。

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

或者使用 render 在启动时解析配置模板：

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

Kubernetes

从保管库创建机密，无需在清单中硬编码值：

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

若要在运行时注入凭据，请将代理作为 Sidecar 容器部署在您的 Pod 中。应用容器将 HTTPS_PROXY 指向该 Sidecar。凭据按请求进行解析，绝不存储在 etcd 中。

IaC

Terraform、Ansible、Pulumi

Terraform

在 terraform apply 之前将凭据解析到提供程序环境中。AWS 提供程序从标准环境变量读取其凭据——Clavitor 会内联填充这些变量，.tf 文件中不会提及任何机密。

$ 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

在您的代码中，provider "aws" {} 块保持为空。同样的模式适用于任何支持环境变量凭据的 Terraform 提供程序（大多数提供程序均支持）。

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

在以下每个示例中，令牌均通过 stdin 管道传递——使其不进入 argv，从而不会出现在 /proc/<pid>/cmdline 或构建日志中。

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

保管库存储的密钥

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

私钥直接通过管道传递给 ssh-add。它绝不落盘，绝不出现在 shell 历史记录中，并在会话结束时从智能体中清除。

旧版系统

只要发起 HTTP 调用，即可正常工作。

代理不限制发起请求的编程语言。无论是 COBOL、FORTRAN、Perl、Visual Basic，还是 30 年前的批处理任务——只要进程发起 HTTPS 请求，代理就会拦截该请求，解析 clavitor:// 引用，并注入真实凭据。无需更改任何代码。

对于无法发起 HTTP 调用的系统，请在进程启动前使用 clavitor-cli render 解析配置模板。模板可安全存储在任何位置。解析后的输出将发送到 stdin 或具有受限权限的临时文件。

# 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