Sign in Бесплатно навсегда Get started

Инфраструктура

Ни одного секрета в конфигурации.

Ни одного секрета в журналах.

Любая платформа, любой оркестратор, любой CI-runner. Прокси работает со всем, что делает 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
# Агент никогда не видит sk_live_... — в журналах присутствует только clavitor://

Контейнеры

Docker и Kubernetes

Docker Compose

Запустите прокси Clavitor на хосте и направьте Ваши контейнеры на него. Учетные данные будут прозрачно внедрены в исходящие запросы — без секретов в переменных окружения, без секретов, встроенных в образы.

# На хосте Docker
$ clavitor-proxy serve &
# docker-compose.yml — контейнеры маршрутизируются через прокси в режиме хоста
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)"

Для внедрения учетных данных во время выполнения, разверните прокси как сайдкар-контейнер в Вашем поде. Контейнеры приложения устанавливают HTTPS_PROXY на сайдкар. Учетные данные разрешаются для каждого запроса, никогда не храня их в etcd.

Инфраструктура как код

Terraform, Ansible, Pulumi

Terraform

Разрешите учетные данные в среде провайдера перед terraform apply. Провайдер AWS считывает свои учетные данные из стандартных переменных окружения — Clavitor заполняет их inline, в .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: Получить пароль базы данных
  command: clavitor-cli get "Production DB" --field password
  register: db_pass
  no_log: true

- name: Настроить приложение
  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: Развернуть
  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 или во временный файл с ограниченными правами доступа.

# Разрешение учетных данных перед запуском пакетного задания
$ 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 для конфигурационных файлов. Каждый секрет разрешается во время выполнения, никогда не сохраняется.