Demo
Demo
База знаний PMTA›Блок <vault>›Директива§ 3.3.23.3

cache-ttl

<vault>

Сколько ключ из хранилища держится в памяти узла
в конфигурации это строкаcache-ttl 24hвнутри блока <vault>
Компромисс между свежестью ключа и походами в хранилище

Умолчание — 24h. Строка задаёт, сколько ключ, полученный из хранилища, живёт в памяти узла, прежде чем его запросят заново.

И отдельная оговорка, о которой легко забыть: отсутствие ключа кэшируется на час всегда. Эту величину строка не меняет — она вшита.

Из этого следуют два разных времени ожидания. Ключ, который изменили в хранилище, доедет до узла за срок из этой строки. Ключ, который добавили после неудачного поиска, доедет не раньше чем через час.

Строка живёт в блоке <vault> вместе с адресом хранилища и токеном доступа.

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

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

Вторая половина — ротация. Смена ключа доезжает до узла за срок из этой строки, и сутки по умолчанию — это сутки, в течение которых узел подписывает старым ключом, снятым из хранилища.

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

Ротация у нас поэтому идёт по своим правилам — новый селектор, ожидание опустошения очередей, снятие старого, — и часовым кэшем отсутствия ключа не осложняется.

Рекомендуемые значения

Что ставить. Срок выбирают по тому, как часто меняются ключи:

Значение Когда
24h (умолчание) ключи меняются по расписанию, и сутки задержки приемлемы
1h–2h ротация частая либо ключ могут отозвать срочно
дольше суток хранилище далеко или ненадёжно, а ключи почти не меняются

Короткий срок стоит похода в хранилище на каждый ключ — и хранилище должно быть доступно в этот момент. Долгий экономит походы ценой задержки при ротации.

Умолчание 24h и часовое кэширование отсутствия ключа — из руководства, § 3.3.23.3. Разбор двух разных времён ожидания и разбивка случаев наши.
Пример в конфигурации
# ротация частая — сутки задержки слишком много
<vault>
    server-url https://10.1.2.3:4500
    access-token akhdfasdhf786282684734kjsdhf
    cache-ttl 2h</vault>
Строка касается найденных ключей. Отсутствие ключа кэшируется на час всегда, и эта величина не настраивается.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Добавляют ключ в хранилище после того, как узел его не нашёл

§ 3.3.23.3

Чем чреватоОтсутствие ключа кэшируется на час, и эта величина не настраивается. Узел не увидит добавленный ключ целый час, сколько ни правь эту строку.
Как заметитьКлюч в хранилище есть, подпись не ставится, ошибок нет.
Как правильноСбросить кэш секретов командой — либо изначально класть ключ в хранилище прежде, чем ссылаться на него.

Оставляют сутки при частой ротации

наш опыт

Чем чреватоСмена ключа доезжает до узла за срок из этой строки. Сутки — это сутки подписи ключом, который в хранилище уже заменили или отозвали.
Как заметитьПосле ротации узел продолжает подписывать прежним селектором.
Как правильноСократить срок либо сбрасывать кэш секретов сразу после ротации.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
cache-ttl <time-interval>
Значения
промежуток времени, например 2h
Умолчание
24h § 3.3.23.3
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<vault>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <vault> и относится ко всему хранилищу: блок один на узел, и своего срока у отдельного ключа быть не может.
⇄

Связанные директивы

2 связи

Работают в паре

domain-keyGlobalКлючи подписи и есть то, что чаще всего берут из хранилища; срок кэша решает, как быстро доедет их смена. § 3.3.23.3Закрыть права на файлы конфигурацииХранилище — альтернатива ключам на диске; права на файл конфигурации это не отменяет. § 3.3.23.3

Как проверить на узле
Строку видно в конфигурации; поведение кэша проверяют временем:
grep -n -A4 '^<vault>' /etc/pmta/config
pmta clear secretscache
Вторая команда сбрасывает кэш секретов — это единственный способ не ждать истечения срока при ротации или после добавления недостающего ключа.
◇

Что ещё почитать

3 статьи

◇Секреты во внешнем хранилищеКлючи подписи можно держать в HashiCorp Vault: в конфигурации остаётся путь, MTA берёт ключ по HTTP и держит в памяти, не записывая на диск.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация ключей · Безопасность узла
Соседние настройки блока <vault>:access-tokenserver-urlВсе 3 директив блока →