Токены

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

Все внешние механизмы аутентификации привязываются к динамически создаваемым токенам. Эти токены обладают всеми теми же свойствами, что и обычный токен, созданный вручную.

Внутри Stronghold токены сопоставляются с неким набором данных. К наиболее важным сопоставляемым данным относится набор из одной или нескольких прикрепленных политик. Эти политики определяют действия, доступные владельцу токена в Stronghold. Также сопоставляются метаданные, которые можно просматривать и которые добавляются в журнал аудита. Например, время создания, время последнего продления токена и др.

Формат токенов

Токены состоят из префикса и тела.

• Префикс указывает на тип токена:

  Тип токена	Префикс
  Служебный (service)	s.
  Пакетный (batch)	b.
  Токен восстановления (recovery)	r.

• Тело представляет собой случайно сгенерированную строку из 24 или более символов (Base62-строка).

Предполагается, что имя токена будет составлено в соответствии со следующим регулярным выражением: [sbr]\.[a-zA-Z0-9]{24,}.

Примеры:

b.n6keuKu5Q6pXhaIcfnC9cFNd
r.JaKnR2AIHNk3fC4SGyyyDVoQ9O
s.raPGTZdARXdY0KvHcWSpp5wWZIHNT

Типы токенов

Существует два типа токенов: служебные (service) и пакетные (batch). Далее приводится подробная информация об их различиях, но сначала следует разобраться в других связанных понятиях. Функции, описанные в следующих разделах, относятся к служебным токенам, а их их применимость к пакетным токенам рассматривается позже.

Хранилище токенов

В документации и справочных материалах часто можно встретить понятие «хранилище токенов». Это понятие совпадает с методом аутентификации Token. Это особый бэкенд, поскольку он отвечает за создание и хранение токенов, и не может быть отключен. Также это единственный метод аутентификации, который не имеет возможности входа в систему. Для выполнения любого действия требуется наличие существующих токенов аутентификации.

Root-токены

Root-токены — это токены, к которым прикреплена root-политика. Root-токенам доступны любые действия в Stronghold. Кроме того, это единственный тип токенов в Stronghold, который может быть настроен так, чтобы срок его действия никогда не истекал, без необходимости продления. Как следствие, создание root-токенов намеренно затруднено. Существует только три способа создания root-токенов:

• Во время выполнения команды d8 stronghold operator init. У этого токена нет срока действия.
• Используя другой root-токен. При этом root-токен с заданным сроком действия нельзя использовать для создания бессрочного root-токена.
• Используя команду d8 stronghold operator generate-root, для выполнения которой требуется кворум держателей ключей для распечатывания хранилища.

Иерархия токенов и осиротевшие токены

Обычно, когда держатель токена создает новые токены, они создаются как дочерние элементы исходного токена. В свою очередь токены, созданные из них, будут дочерними по отношению к ним и так далее. При отзыве родительского токена отзываются и все его дочерние токены, а также их аренды. Это гарантирует, что пользователь не сможет избежать момента отзыва токенов, сгенерировав бесконечное число дочерних токенов.

Часто такое поведение бывает нежелательно, и в этом случае пользователи с соответствующим уровнем доступа могут создавать «осиротевшие» (orphan) токены. У этих токенов нет родительского токена. Их можно создать одним из следующих способов:

• С помощью доступа уровня write к эндпоинту auth/token/create-orphan.
• С помощью доступа уровней sudo или root к auth/token/create и установив параметр no_parent в значение true.
• Через роли хранилища токенов.
• После аутентификации с помощью любого другого метода, кроме Token.

Пользователи с соответствующими правами могут также использовать эндпоинт auth/token/revoke-orphan, который отзывает указанный токен, но при этом вместо отзыва всех дочерних токенов, делает группу непосредственных дочерних токенов «осиротевшими». Используйте данный эндпоинт с осторожностью!

Идентификаторы доступа к токену

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

• поиск свойств токена (исключая фактический идентификатор токена);
• поиск возможностей токена по заданному пути;
• обновление токена;
• отзыв токена.

Логи аудита могут быть настроены на то, чтобы не обфусцировать идентификаторы доступа токенов в журналах аудита. Это даёт возможность быстро отозвать токены в случае крайней необходимости. Однако это также означает, что журналы аудита могут быть использованы для проведения более масштабной DDoS-атаки.

Наконец, единственный способ получить список токенов — это команда auth/token/accessors, которая на самом деле выводит список идентификаторов доступа токенов. Хотя это всё ещё опасный эндпоинт (поскольку вывод списка всех идентификаторов доступа означает, что они могут быть быть использованы для отзыва всех токенов), это также предоставляет возможность проведения аудита и отзыва активных в данный момент токенов.

Время жизни токена, периодические токены и явный максимальный TTL

У каждого не-root-токена есть определённый срок действия (TTL), который представляет собой текущее время жизни с момента создания токена или с момента последнего обновления — в зависимости от того, что произошло раньше. У root-токенов может быть свой TTL, но при этом он может быть равен нулю, что указывает на бессрочность токена. После того как TTL истечёт, токен больше не будет функционировать — он и связанные с ним аренды, будут отозваны.

Если токен продлеваемый, можно попросить Stronghold продлить срок его действия, используя команду d8 stronghold token renew или выполнив запрос к соответствующему API-эндпоинту. Далее на результат могут оказывать влияние различные факторы. Результат зависит от того, является ли токен является периодическим (может быть создан root- и sudo-пользователями, через роли в хранилище токенов или иные методы аутентификации) и имеет ли он явный максимальный TTL.

Общий случай

В общем случае, когда токен не является периодическим и у него нет явно указанного максимального значения TTL, время жизни токена с момента его создания будет сравниваться с максимальным TTL. Это максимальное значение TTL генерируется динамически и может меняться между продлениями, поэтому значение не будет отображаться при поиске информации о токене. Оно основано на сочетании следующих факторов:

1. Максимальный TTL по умолчанию в системе составляет 32 дня, но может быть изменён.
2. Максимальный TTL, установленный для монтирования с помощью mount tuning. Это значение может иметь приоритет перед максимальным TTL системы, оно может быть длиннее или короче, и если это значение установлено, то оно будет соблюдаться.
3. Значение, предложенное методом аутентификации, который выдал токен. Оно может быть настроено для каждой роли, группы или пользователя. Это значение может быть меньше, чем максимальный TTL монтирования (или, если оно не задано, максимальный TTL системы), но не может быть больше.

Обратите внимание, что значения в (2) и (3) могут измениться в любой момент времени, поэтому окончательное определение текущего допустимого максимального TTL производится в момент продления токена с использованием текущих значений. Также по этой причине важно всегда быть уверенным в том, что TTL, возвращаемый в результате операции продления, находится в допустимом диапазоне; если это значение не расширяется, то, скорее всего, TTL токена не может быть расширен за пределы его текущего значения, и клиент может захотеть пройти повторную аутентификацию и получить новый токен. Однако за пределами прямого взаимодействия с оператором Stronghold никогда не будет отзывать токен до истечения возвращенного TTL.

Явные максимальные значения TTL

Для токенов может быть явно задано максимальное значение TTL. Это значение является жестким ограничением времени жизни токена. Независимо от значений в (1), (2) и (3) пунктах из общего случая, токен не может действовать дольше этого явно установленного значения. Это работает даже при использовании периодических токенов, чтобы выйти за рамки обычного механизма TTL.

Периодические токены

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

• используя возможность sudo или root-токен через эндпоинт auth/token/create;
• используя роли хранилища токенов;
• используя метод аутентификации, который поддерживает их выпуск, например AppRole.

В момент выпуска TTL периодического токена будет равен периоду, указанному в настройках. При каждом продлении TTL будет сбрасываться до этого настроенного периода, и пока токен будет успешно продлеваться, срок его действия никогда не истечет. За исключением root-токенов, это единственный способ для токена в Stronghold иметь неограниченное время жизни.

Идея периодических токенов заключается в том, что системам и службам легко даётся выполнение какого-либо частого действия — например, каждые два часа или даже каждые пять минут. Следовательно, пока система активно обновляет этот токен (иными словами, пока система жива), ей разрешается продолжать использовать токен и все связанные с ним аренды. Однако если система перестанет обновлять токены в течение этого периода (например, если она была выключена), срок действия токена истечет довольно быстро. Рекомендуется, чтобы этот период был как можно короче, и, говоря в целом, не следует давать людям периодические токены.

При использовании периодических токенов необходимо знать несколько важных моментов:

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

Токены с привязкой к CIDR

Некоторые токены могут быть привязаны к CIDR, которые ограничивают диапазон клиентских IP-адресов, которым разрешено их использовать. Это касается всех токенов, кроме бессрочных root-токенов (у которых TTL равен нулю). Если у root-токена есть срок действия, на него также распространяется привязка к CIDR.

Подробнее о типах токенов

В настоящее время существует два типа токенов.

Служебные токены

Служебные токены — это то, что пользователи обычно воспринимают как «обычные» токены Stronghold. Они поддерживают все функции, такие как продление, отзыв, создание дочерних токенов и др. Соответственно, есть определенные сложности в их создании и отслеживании.

Пакетные токены

Пакетные токены — это зашифрованные «блобы» (blobs), которые содержат достаточно информации для использования в операциях Stronghold и при этом не требуют места на диске для их отслеживания. В результате они хорошо масштабируются, но лишены гибкости и большинства возможностей, присущих служебным токенам.

Сравнение типов токенов

В этой таблице показана разница в поведении служебных и пакетных токенов.

Работа с арендами служебных и пакетных токенов

Сервисные токены

Аренды, создаваемые служебными токенами (включая аренды дочерних токенов), отслеживаются вместе с токенами и отзываются по истечении срока действия токена.

Пакетные токены

Аренды, создаваемые пакетными токенами, ограничены оставшимся TTL пакетных токенов и, если пакетный токен не относится к «осиротевшим», отслеживаются его родителем. Аренды аннулируются, когда истекает TTL пакетного токена или когда отзывается родитель пакетного токена (в этот момент у пакетного токена также перестаёт работать доступ к Stronghold).