Инфраструктура
Никаких секретов в конфигурации. Никаких секретов в логах.
Любая платформа, любой оркестратор, любой CI-раннер. Прокси работает с чем угодно, что делает HTTP-запросы. CLI работает с чем угодно, что может выполнить команду оболочки. Если ваша система старше вашей карьеры, она всё равно будет работать.
Прокси — это универсальная интеграция.
Если ваша рабочая нагрузка выполняет 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-контейнера в вашем поде. Контейнеры приложений устанавливают 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. Он никогда не касается диска, никогда не появляется в истории командной строки и удаляется из агента по окончании сеанса.
Устаревшие системы
Если он делает 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
Шаблон всегда один и тот же.
CLI для скриптов и конвейеров. Прокси для HTTP-нагрузок. Render для файлов конфигурации. Любой секрет разрешается во время выполнения, никогда не хранится.