Перейти к содержанию

SOPS + age: хранить зашифрованные конфиги в Git

Безопасность · Секреты
Не изучено

Добавлено 2026-10-11. Нужны SOPS и age; пример сначала выполнять в отдельном учебном каталоге.

Проблема

Секретные настройки исключены из Git, но передаются вручную и теряются при переезде. Хранить открытый .env в истории репозитория нельзя.

Решение

SOPS шифрует значения конфигурации, а публичный age-recipient задаёт, кто сможет её расшифровать. Закрытый ключ хранить отдельно от репозитория и бэкапить отдельно от зашифрованных файлов. Для production CI заранее определить, какой runner получает ключ и при каких условиях.

Пример

Создать отдельный ключ вне Git. test ! -e предотвращает случайную замену существующего ключа. Выполнять блок как скрипт Bash.

#!/usr/bin/env bash
set -euo pipefail
umask 077
key_dir="$HOME/.config/devops-kb-secrets"
mkdir -p "$key_dir"
export SOPS_AGE_KEY_FILE="$key_dir/age-key.txt"
test ! -e "$SOPS_AGE_KEY_FILE"
age-keygen -o "$SOPS_AGE_KEY_FILE"
age-keygen -y "$SOPS_AGE_KEY_FILE"

Последняя команда выводит публичный recipient. В учебном каталоге создать .sops.yaml, заменив строку REPLACE_WITH_PUBLIC_AGE_RECIPIENT этим значением:

creation_rules:
  - path_regex: '^secrets/.*\.yaml$'
    age: 'REPLACE_WITH_PUBLIC_AGE_RECIPIENT'

Шифруются значения всего YAML. Имена ключей и структура остаются видимыми. Первую проверку выполнить на заведомо несекретных данных:

#!/usr/bin/env bash
set -euo pipefail
umask 077
export SOPS_AGE_KEY_FILE="$HOME/.config/devops-kb-secrets/age-key.txt"
mkdir -p secrets
test ! -e secrets/demo.yaml
printf 'token: DEMO_NOT_A_REAL_SECRET\n' > secrets/demo.yaml
sops encrypt --in-place secrets/demo.yaml
sops decrypt secrets/demo.yaml > /dev/null

Перед добавлением в Git проверить, что token содержит ENC[...], а файл — метаданные sops. В дальнейшей работе использовать sops edit secrets/demo.yaml; не направлять расшифрованный вывод в CI-лог. Значение из примера — только тест. Саму .sops.yaml можно хранить в Git: в ней публичный recipient, а не закрытый ключ.

Когда применять

Для небольшого набора статических конфигов и GitOps. Если нужны короткоживущие учётные данные и централизованный отзыв доступа, одного SOPS недостаточно. Шифрование новой версии не убирает старый открытый секрет из истории: ранее раскрытый секрет нужно заменить.

Источник

Как применить у себя

  1. Проверить round-trip на учебном файле и восстановление ключа из резервной копии.
  2. Разделить ключи окружений и задокументировать получателей.
  3. Убедиться, что закрытого ключа и открытого секрета нет в diff, Git и логах.
  4. После безопасной доставки одного реального конфига отметить «Изучено».