Предельные и максимальные значения в StarVault

Максимальный размер объекта, записываемого в бэкенд хранения, определяется самим бэкендом.

По умолчанию предельный размер записи для бэкенда встроенного хранилища составляет 1 МиБ. Допустимый размер записи настраивается с помощью параметра max_entry_size в строке файла конфигурации хранилища.

Прежде чем вносить запись в Raft, StarVault автоматически разбивает любую запись в хранилище, размер которой больше 512 КиБ, но меньше max_entry_size.

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

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

Все точки монтирования механизма секретов и точки монтирования аутентификации должны умещаться в одной записи хранилища. Размер каждого объекта JSON с описанием точки монтирования составляет около 500 байт, но в сжатом виде и обычно занимает около 75 байт. Каждая из точек монтирования аутентификации, механизма секретов, чисто локальных методов аутентификации и чисто локального механизма секретов хранится отдельно, поэтому ограничение применяется к каждой из них отдельно.

Указание особых параметров для каждой точки монтирования или использование длинных путей к точкам монтирования увеличивает объем пространства, требуемого для каждой точки монтирования.

Считывая конечные точки sys/auth и sys/mounts можно отследить количество точек монтирования.

Как вариант, используйте метрики телеметрии vault.core.mount_table.num_entries и vault.core.mount_table.size, чтобы отслеживать количество точек монтирования и размер каждой таблицы монтирования.

Метаданные, которые прикрепляются к объекту. "удостоверение" или группе объектов, подпадают под следующие ограничения:

StarVault разбивает объекты на сегменты, распределяя их между 256 записями хранилища. Псевдонимы объектов хранятся внутри элементов типа "Объект" и поэтому занимают тот же пул памяти. Определения объектов сжимаются в каждой записи хранилища, и размер до сжатия зависит от количества псевдонимов объектов и объема метаданных. Минимально заполненные объекты после сжатия занимают около 200 байт.

Определения групп хранятся отдельно в собственном пуле из 256 записей хранилища. Размер каждого элемента типа "Группа" зависит от количества членов группы и объема метаданных. Псевдонимы группы и информация о ее составе хранятся в каждом элементе типа "Группа". Группа без метаданных, которая содержит 10 объектов, будет занимать около 500 байт, а группа со 100 объектами будет занимать около 4 000 байт.

В таблице ниже приведены как наилучшие, так и консервативные оценки для объектов и групп. Значения указаны чуть меньше, чем тот объем, который помещается в один сегмент, так как первый же заполненный сегмент будет вызывать сбои. Максимальное значение уменьшится, если каждый объект будет содержать большой объем метаданных или каждая группа будет иметь большое количество членов.

Количество объектов идентификации, которые отслеживаются с помощью телеметрии StarVault — vault.identity.num_entities.

Накладные расходы на обновление объектов и групп растут по мере увеличения количества объектов в каждом сегменте. Эти расходы отслеживаются с помощью метрик vault.identity.upsert_entity_txn и vault.identity.upsert_group_txn.

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

Для каждого токена используется одна запись хранилища, поэтому максимальное количество активных токенов не ограничено. На поле метаданных токена не налагается никаких ограничений, кроме того, что токен должен помещаться в одну запись хранилища:

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

При каждом использовании токена StarVault собирает коллекцию прикрепленных политик: к токену, к объекту, к любым группам, в которые входит объект, и к рекурсивно к любым группам, в которые входят эти группы. Очень большое количество политик использовать можно, но это приведет к увеличению времени отклика StarVault. Отслеживайте метрику vault.core.fetch_acl_and_token, чтобы определить, не становится ли время, необходимое для составления списка контроля доступа, чрезмерно большим.

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

Метаданные каждой версии занимают 21 байт и должны помещаться в одной записи хранилища отдельно от хранимых данных.

Каждый секрет также имеет метаданные, не зависящие от версии. Эти данные могут содержать поле custom_metadata с парами ключ-значение, которые предоставил пользователь. StarVault устанавливает следующие предельные значения для пользовательских метаданных:

Максимальный размер зашифрованного или незашифрованного текста Transit ограничен максимальным размером запроса StarVault, как описано ниже.

Все архивные версии одного ключа должны умещаться в одну запись хранилища. Это предельное значение зависит от размера ключа.

Максимальный размер HTTP-запроса в StarVault ограничивается параметром max_request_size в строке конфигурации обработчика. По умолчанию равен 32 МиБ.
Это значение, за вычетом размера самого HTTP-запроса, задает верхнее предельное значение для операции Transit и максимальный размер секретов в формате ключ-значение.

Максимальная продолжительность операции StarVault определяется значением max_request_duration, которое по умолчанию равно 90 секундам. Если определенному механизму секретов требуется больше времени для выполнения операции на удаленном сервисе, клиент StarVault увидит сбой.

Переменная окружения VAULT_CLIENT_TIMEOUT также задает максимальную продолжительность на стороне клиента, которая по умолчанию составляет 60 секунд.

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

Следите за загрузкой процессора и сети активного узла StarVault и за задержкой между последней записью в журнал WAL и в журнал WAL реплик, чтобы определить превышение максимального количества реплик.

Для предельного значения аренды настраиваются общесистемные параметры maximum TTL и maximum TTL per mount point.

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

Текущее количество неистекших аренд отслеживается с помощью метрики vault.expire.num_leases.

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

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