<vault>

Внешнее хранилище секретов
Секреты не в файлах узла, а в отдельном хранилище

Две строки — адрес и токен — и с этого момента узел умеет читать секреты из внешнего хранилища вместо своих файлов.

Что можно туда унести. Ключи подписи (domain-key), сертификат для приёма почты и пароль к его закрытому ключу (smtp-server-tls-certificate), а также проверку пароля подачи через LDAP (authentication-method со значением {vault}:ldap).

Ссылка записывается прямо в директиве — вместо пути пишется {vault}:путь/ключ. Конфигурация при этом остаётся читаемой: в ней видно, откуда берётся секрет, но не сам секрет.

Блок один на узел. Двух хранилищ быть не может.

Токен создаётся вручную на стороне Vault и в конфигурации лежит открытым текстом — то есть один секрет всё-таки остаётся на узле, но один вместо многих, и отзывается он в одном месте.

Пример в конфигурации
# адрес и токен — всё, что нужно для подключения
<vault>
    server-url https://myvault:4500
    access-token akhdfasdhf786282684734kjsdhf
</vault>

# дальше секреты берутся ссылкой вместо пути
smtp-server-tls-certificate {vault}:/v1/kv/data/tlsCerts:smtp-cert
Пример руководства. В конфигурации остаётся только токен; ключи, сертификаты и пароли к ним живут в хранилище и в резервные копии узла не попадают.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация ключей