Secrets Management (Управление секретами)

Secrets Management — это системный подход к защите, хранению, передаче и использованию конфиденциальной информации в ИТ-инфраструктуре. Секретами называют чувствительные данные, такие как:

• пароли,
• API-ключи,
• токены доступа,
• SSH-ключи,
• TLS/SSL-сертификаты,
• ключи шифрования и базы данных.

Утечка таких данных может привести к взлому, несанкционированному доступу к системам, потере данных и серьёзным репутационным и юридическим последствиям. Поэтому управление секретами — обязательный элемент стратегии безопасности любой современной ИТ-системы.

Основные задачи Secrets Management

• Хранение — защита секретов в зашифрованном виде, с контролем доступа;
• Ротация — автоматическая или ручная смена ключей, токенов, паролей;
• Доступ — выдача секретов приложениям и пользователям по принципу минимальных прав;
• Аудит — ведение логов доступа к секретам для анализа и соответствия требованиям;
• Интеграция — работа с CI/CD, контейнерами, сервисами в Kubernetes и облачных платформах.

Популярные инструменты управления секретами

Пример: создание и использование Kubernetes Secret

kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=securepass

env:
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: username

📌 Переменные окружения в контейнере будут загружены из секретов в Kubernetes.

Зачем это важно

• Изоляция конфиденциальных данных от кода — секреты не должны храниться в git, .env, .yaml и т.д.;
• Контроль доступа — только авторизованные сервисы и пользователи получают доступ;
• Аудит и соответствие стандартам — SOC 2, ISO 27001, PCI DSS, HIPAA и др.;
• Защита в облачных и CI/CD-средах — автоматическая выдача секретов в рантайме без ручного вмешательства;
• Масштабируемость и унификация — централизованное управление для десятков сервисов, сред и окружений.

Best Practices

• Никогда не храните секреты в открытом виде в git-репозиториях;
• Используйте централизованное хранилище секретов (Vault, Secrets Manager, Key Vault);
• Включайте шифрование at rest и in transit для секретов;
• Применяйте RBAC или IAM для ограничения доступа;
• Настраивайте автоматическую ротацию секретов, особенно для баз данных и API;
• Интегрируйте секреты в CI/CD пайплайны с минимальным временем жизни (short-lived credentials);
• В Kubernetes — избегайте plaintext-секретов, применяйте KMS-поддержку или external-secrets-операторы.

Secrets Management — это критическая часть безопасной DevOps-платформы. Он обеспечивает надёжную защиту чувствительных данных в динамических инфраструктурах и автоматизированных процессах, таких как CI/CD, облачные сервисы, микросервисы и Kubernetes.

Практические примеры конфигураций для Secrets Management, включая Vault, Kubernetes и облачные хранилища — с фокусом на безопасное использование в CI/CD и production-средах.

1. HashiCorp Vault: выдача dynamic credentials для PostgreSQL

➊ Конфигурация роли:

path "database/creds/readonly" {
  capabilities = ["read"]
}

➋ Vault: подключение к PostgreSQL и создание роли

vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly" \
  connection_url="postgresql://vaultuser:password@postgres.internal.local:5432/postgres?sslmode=disable"

vault write database/roles/readonly \
  db_name=postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

📌 Запрос к database/creds/readonly возвращает временные уникальные логин/пароль.

2. Kubernetes External Secrets (KES + AWS Secrets Manager)

Secret в AWS:

{
  "username": "db_admin",
  "password": "strongpass123"
}

ExternalSecret CRD в Kubernetes:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  secretStoreRef:
    name: aws-secrets
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: username
      remoteRef:
        key: prod/db
        property: username
    - secretKey: password
      remoteRef:
        key: prod/db
        property: password

📌 Секреты автоматически подтягиваются из AWS и используются подами как обычные Secret.

3. GitOps подход: SOPS + Git + Sealed Secrets

Зашифрованный секрет через Mozilla SOPS:

apiVersion: v1
kind: Secret
metadata:
  name: app-creds
  namespace: default
sops:
  encrypted_regex: '^(data|stringData)$'
  creation_rules:
    - pgp: <YOUR_PGP_KEY>
data:
  password: ENC[AES256_GCM,data:...,type:str]

📌 Такой файл можно коммитить в Git — дешифруется только при применении в кластере с нужным ключом.

4. Terraform + AWS Secrets Manager

resource "aws_secretsmanager_secret" "db" {
  name = "prod/db"
}

resource "aws_secretsmanager_secret_version" "db_creds" {
  secret_id     = aws_secretsmanager_secret.db.id
  secret_string = jsonencode({
    username = "admin"
    password = "supersecure"
  })
}

📌 Инфраструктура секретов создаётся через код, легко встраивается в CI/CD.

🛡️ Best practices checklist:

• Используешь короткоживущие ключи (TTL ≤ 1ч)
• Автоматическая ротация (например, Vault + database plugin)
• RBAC/IAM для доступа к секретам
• Аудит логов запросов к секретам (Vault audit, AWS CloudTrail)
• Secrets не хранятся в git в открытом виде
• Используешь sealed или external secrets при GitOps