Skip to main content

​
Зачем отдельно управлять секретами

Пароли, API-ключи, сертификаты не должны лежать в коде, в логах или в открытом виде в конфигах. Нужно централизованное хранилище, контроль доступа и безопасная доставка в приложение и пайплайны.

​
Варианты хранения

Хранение секретов, динамические credentials для БД/облака, политики доступа. Интеграция с K8s (CSI driver, sidecar).
AWS Secrets Manager, GCP Secret Manager, Azure Key Vault — интеграция с IAM и приложениями в том же облаке.
Базовый вариант: объекты Secret в кластере; не шифруются по умолчанию at rest — нужны политики RBAC и опционально encryption at rest / external secrets.
Секреты в переменных пайплайна (GitHub Secrets, GitLab CI variables) — только для нужд сборки/деплоя, не подставлять в образы как константы.

​
Практики

  • Не коммитить секреты; использовать .gitignore и pre-commit хуки (detect-secrets, gitleaks).
  • В приложении — получать секреты при старте из хранилища или из окружения (injected из K8s/VM).
  • Ротация ключей и паролей по политике; минимальный срок жизни для временных credentials.

​
Что добавить сюда

  • Выбранное хранилище и схема доставки в свои приложения
  • Примеры настройки Vault или облачного Secret Manager
  • Ссылки на документацию и best practices