NATS Core, доставка и полномочия¶
Требования применяются к выбору режима NATS, Core NATS request/reply и общей
границе полномочий NATS-клиента. Уровни обязательности определены в корневом
README.md.
INT-NATS-001. Выбор режима доставки¶
Уровень: MUST
Применяется к: взаимодействию через NATS
Контракт должен явно выбирать один из режимов:
- Core NATS publish/subscribe — только для данных, потеря которых при отсутствии subscriber, разрыве соединения или restart допустима;
- Core NATS request/reply — для ограниченного запросом ответа без требования сохранить запрос до появления responder;
- JetStream — когда требуются сохранение, replay, подтверждение обработки или восстановление позиции consumer.
Core NATS не должен использоваться как надёжная очередь посредством неограниченного локального буфера или предположения, что subscriber всегда доступен. Для нового горизонтально масштабируемого JetStream consumer следует использовать durable pull consumer с explicit acknowledgement, если иной режим не подтверждён контрактом доставки.
Обоснование¶
Core NATS и JetStream имеют разные гарантии потери, повторной доставки и восстановления; общий client API не делает эти режимы взаимозаменяемыми.
Проверка¶
- сопоставление каждого subject с выбранным режимом и допустимой потерей;
- тест отсутствующего subscriber, reconnect и restart;
- тест восстановления durable consumer и повторной доставки без ack;
- проверка отсутствия неограниченного client buffer.
Исключения¶
Ephemeral или ordered consumer MAY применяться для диагностики и воспроизводимой проекции, если потеря позиции не нарушает обязательный результат.
INT-NATS-005. NKey и полномочия subject¶
Уровень: MUST
Применяется к: аутентификации NATS-клиента посредством NKey
Каждый компонент и окружение должны использовать отдельную user identity.
Public NKey MAY находиться в открытой конфигурации; NKey seed должен считаться
production-секретом, поступать через механизм SEC-SCRT-006, не передаваться
серверу и не попадать в Git, image, environment dump, log или telemetry.
Полномочия identity должны задавать минимальные allow/deny для publish, subscribe, queue group и JetStream API subjects. Requestor должен получать только собственное пространство reply inbox. Responder должен использовать ограниченное разрешение ответа с конечными числом ответов и сроком либо более узкий явный allowlist.
NKey challenge не заменяет TLS по SEC-TLS-001 и проверку сервера по
SEC-TLS-002. Проект должен иметь проверяемую процедуру ротации и отзыва seed
или связанного user JWT без переиспользования identity между компонентами.
Обоснование¶
NKey доказывает владение закрытым ключом, но не шифрует соединение и сам по себе не ограничивает subjects; общий seed увеличивает область компрометации.
Проверка¶
- тест подключения с действующим, отозванным и чужим NKey;
- secret scanning исходников, image, логов и telemetry;
- негативный тест каждого запрещённого publish, subscribe и queue group;
- тест ограничения reply и ротации credentials при работающих экземплярах.
Исключения¶
Синтетическая identity MAY совместно использоваться только внутри изолированного локального теста; production-equivalent тест полномочий и ротации остаётся обязательным.
INT-NATS-006. Контракт request/reply¶
Уровень: MUST
Применяется к: взаимодействию через NATS request/reply
Requestor должен иметь конечный deadline и различать отсутствие responder, истечение deadline без ответа и ответ прикладного отказа. Ответ после deadline не должен изменять уже завершённый результат операции.
Обоснование¶
Отсутствие subscriber, медленный responder и прикладной отказ требуют разных решений вызывающей стороны.
Проверка¶
- тест no-responder, timeout, позднего ответа и прикладного отказа.
Исключения¶
Не допускаются.
INT-NATS-008. Единственный responder¶
Уровень: MUST
Применяется к: NATS request/reply с несколькими взаимозаменяемыми экземплярами responder
Все экземпляры одного логического responder должны состоять в одной объявленной queue group. Один запрос должен передаваться одному экземпляру этой группы и создавать не более одного прикладного ответа.
Разные обработчики с разной семантикой не должны совместно использовать одну queue group.
Обоснование¶
Обычная subscription доставляет запрос каждому экземпляру, а общая queue group разных обработчиков случайно выбирает семантику ответа.
Проверка¶
- запрос конфигурации subscription и queue group;
- серия запросов при нескольких экземплярах с проверкой единственного ответа;
- негативный тест разных обработчиков в одной queue group.
Исключения¶
Единственный responder не требует queue group. Broadcast-сценарий с несколькими ответами должен использовать отдельный явно определённый контракт, а не выдаваться за request/reply с одним результатом.