Cero secretos en la configuración. Cero secretos en los registros.

El proxy es la integración universal.

Si su carga de trabajo realiza llamadas HTTPS, el proxy de Clavitor inyecta credenciales en la capa de red. Sin cambios en el código. Sin SDK. Sin secretos en variables de entorno, archivos de configuración o registros. Configure HTTPS_PROXY y su código existente funcionará sin cambios: el proxy resuelve las referencias clavitor:// en las cabeceras de solicitud antes de que la solicitud salga de la máquina.

$ 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

Contenedores

Docker y Kubernetes

Docker Compose

Ejecute el proxy de Clavitor en el host y apunte sus contenedores hacia él. Las credenciales se inyectan de forma transparente en las solicitudes salientes; no hay secretos en las variables de entorno ni secretos incrustados en las imágenes.

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

O utilice render para resolver una plantilla de configuración al inicio:

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

Kubernetes

Cree secretos desde la bóveda sin codificar valores en manifiestos:

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

Para la inyección de credenciales en tiempo de ejecución, implemente el proxy como un contenedor sidecar en su pod. Los contenedores de aplicaciones configuran HTTPS_PROXY al sidecar. Las credenciales se resuelven por solicitud, nunca se almacenan en etcd.

IaC

Terraform, Ansible, Pulumi

Terraform

Resuelva credenciales en el entorno del proveedor antes de terraform apply. El proveedor de AWS lee sus credenciales de variables de entorno estándar; Clavitor las rellena en línea, el archivo .tf no menciona ningún secreto.

$ 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

El bloque provider "aws" {} permanece vacío en su código. El mismo patrón funciona para cualquier proveedor de Terraform que admita credenciales de variables de entorno (que son la mayoría).

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

El token se pasa por stdin en cada ejemplo a continuación, manteniéndolo fuera de argv para que no aparezca en /proc/<pid>/cmdline ni en los registros de compilación.

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

Claves almacenadas en la bóveda

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

La clave privada se pasa directamente a ssh-add. Nunca toca el disco, nunca aparece en el historial del shell y se elimina del agente cuando finaliza la sesión.

Sistemas heredados

Si realiza una llamada HTTP, funciona.

Al proxy no le importa qué lenguaje realizó la solicitud. COBOL, FORTRAN, Perl, Visual Basic, un trabajo por lotes de 30 años; si el proceso realiza una solicitud HTTPS, el proxy la intercepta, resuelve la referencia clavitor:// e inyecta la credencial real. No se requieren cambios en el código.

Para sistemas que no pueden realizar llamadas HTTP, utilice clavitor-cli render para resolver una plantilla de configuración antes de que comience el proceso. La plantilla es segura para almacenar en cualquier lugar. La salida resuelta va a stdin o a un archivo temporal con permisos restringidos.

# 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