Как организовать хранение и доступ к секретам в DevOps-стеке?

«Как организовать хранение и доступ к секретам в DevOps-стеке?» — вопрос из категории Безопасность, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В DevOps я использую многоуровневый подход к управлению секретами, где ни один секрет никогда не попадает в исходный код или образы.

1. Специализированный Vault (ядро системы): Основное хранилище — HashiCorp Vault. Он обеспечивает шифрование, детальный контроль доступа (через политики), аудит и динамические секреты (например, временные учетные данные БД).

# Запись секрета
vault kv put kv/myapp/prod db_pass="s3cr3t_p@ss" api_key="xyz"

# Генерация динамических секретов для PostgreSQL
vault write database/roles/my-role db_name=myapp creation_statements="CREATE ROLE..."

2. Интеграция с Orchestrator (Kubernetes): В Kubernetes НЕ использую нативные Secrets в plaintext. Вместо этого:

  • External Secrets Operator (ESO): Оператор, который автоматически синхронизирует секреты из Vault (или AWS Secrets Manager, Azure Key Vault) в Kubernetes Secrets. Это сохраняет связь с центральным хранилищем.
  • CSI Provider for Vault: Позволяет монтировать секреты напрямую в pod'ы как тома, что безопаснее, чем переменные окружения.

3. Безопасность в CI/CD пайплайнах: Секреты в пайплайнах (GitLab CI, GitHub Actions, Jenkins) задаются как защищенные переменные (protected variables) или используют временные OIDC-токены для облачных провайдеров.

# GitLab CI - получение секрета из Vault для сборки
job:
  id_tokens:
    VAULT_ID_TOKEN:
      aud: https://gitlab.company.com
  script:
    # Аутентификация в Vault с помощью JWT из GitLab
    - export VAULT_TOKEN=$(curl --request POST --data "{"jwt": "$CI_JOB_JWT", "role": "gitlab-runner"}" $VAULT_ADDR/v1/auth/jwt/login | jq -r .auth.client_token)
    - export DB_PASS=$(vault kv get -field=db_pass kv/myapp/prod)
    - docker build --build-arg DB_PASS=$DB_PASS .

4. Для разработчиков и локальных сред: Использую Vault Agent с режимом Auto-Auth (например, через Kubernetes Service Account или AWS IAM) для безопасного получения секретов на локальные машины или в dev-среды, исключая ручной ввод.

5. Аудит и ротация: Все операции с Vault логируются и отправляются в SIEM. Настраиваю автоматическую ротацию статических секретов и использую краткосрочные lease для динамических, минимизируя окно уязвимости.