⚙️ Теория
🔁 Dynamic secrets для БД
Vault может выдавать временные учетные данные к PostgreSQL:
- креды создаются on-demand;
- имеют ограниченный TTL;
- автоматически ревокуются по истечении срока.
Это снижает риск утечки статичных паролей.
🔐 Transit secrets engine
Transit предоставляет крипто-операции через API:
- шифрование/дешифрование;
- подпись/верификация;
- ротация ключей.
Ключи остаются в Vault; приложение получает результат операции, а не сырой ключ.
⚠️ Риски неправильной эксплуатации
- слишком большой TTL для dynamic creds;
- отсутствие автоматического revoke при offboarding;
- смешивание прод и тест ключей в одном policy пространстве.
❓ Что нужно уметь объяснить
Почему dynamic secrets лучше статичных?
Потому что уменьшается время жизни компрометированного секрета и упрощается массовая ротация.
Когда Transit особенно полезен?
Когда нужно "шифрование как сервис" с централизованным управлением ключами и аудитом операций.
Где частый operational gap?
Приложение не готово корректно обновлять истекающие креды и теряет доступ при ротации.
🧪 Практика
1. Конфигурация PostgreSQL engine (идея)
vault secrets enable database
vault write database/config/my-postgres \
plugin_name=postgresql-database-plugin \
allowed_roles="app-role" \
connection_url="postgresql://{{username}}:{{password}}@db:5432/postgres?sslmode=require" \
username="vaultadmin" \
password="<admin-pass>"
2. Получение динамических кредов
vault read database/creds/app-role
3. Transit: encrypt/decrypt
vault secrets enable transit
vault write -f transit/keys/app-key
vault write transit/encrypt/app-key plaintext=$(echo -n "secret" | base64)
4. Guardrails
- короткие TTL для DB creds;
- автоматический renew/reload в приложении;
- ротация transit-ключей по графику;
- аудит API-операций Vault.
🧾 Вывод
Dynamic secrets и Transit дают практичную модель "минимального времени жизни секрета" и централизованного контроля криптоопераций. Это заметно снижает операционный риск по сравнению со статичными секретами.