Политики

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

Политики по умолчанию запрещают, поэтому пустая политика не предоставляет никаких разрешений в системе.

Процесс авторизации

Прежде чем человек или машина смогут получить доступ, администратор должен настроить Stronghold с помощью метода аутентификации. Аутентификация — это процесс, посредством которого информация, предоставленная человеком или машиной, проверяется по внутренней или внешней системе.

Рассмотрим следующую схему, которая иллюстрирует шаги, которые должна предпринять группа безопасности для настройки Stronghold для аутентификации с использованием корпоративной установки LDAP или ActiveDirectory. Несмотря на то, что в этом примере используется LDAP, эта концепция применима ко всем методам аутентификации.

Команда безопасности настраивает Stronghold для подключения к методу аутентификации. Эта конфигурация зависит от метода аутентификации. В случае LDAP Stronghold необходимо знать адрес сервера LDAP и то, следует ли подключаться с использованием TLS. Важно отметить, что Stronghold не хранит копию базы данных LDAP — Stronghold делегирует аутентификацию методу аутентификации.

Команда безопасности создает политику (или использует существующую политику), которая предоставляет доступ к путям в Stronghold. Политики пишутся в HCL в редакторе по вашему выбору и сохраняются на диске.

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

Самое главное, группа безопасности сопоставляет данные в методе аутентификации с политикой. Например, группа безопасности может создавать такие сопоставления:

Члены группы OU «dev» сопоставляются с политикой Stronghold с именем «readonly-dev».

или

Члены группы OU «ops» сопоставляются с политиками Stronghold «admin» и «auditor».

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

Пользователь пытается пройти аутентификацию, используя свои учетные данные LDAP, предоставляя Stronghold свое имя пользователя и пароль LDAP.

Stronghold устанавливает соединение с LDAP и запрашивает у сервера LDAP проверку предоставленных учетных данных. Сервер LDAP возвращает информацию о пользователе, включая группы OU.

Stronghold сопоставляет результат с сервера LDAP с политиками, используя сопоставление, настроенное группой безопасности в предыдущем разделе. Затем Stronghold генерирует токен и прикрепляет соответствующие политики.

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

Затем пользователь использует этот токен Stronghold для будущих операций. Если пользователь снова выполнит шаги аутентификации, он получит новый токен. Токен будет иметь те же разрешения, но фактический токен будет другим. Аутентификация во второй раз не делает исходный токен недействительным.

Как писать политики

Политики пишутся в HCL или JSON и описывают, к каким путям в Stronghold пользователю или машине разрешен доступ.

Вот очень простая политика, которая предоставляет возможности чтения пути KVv1 “secret/foo”:

path "secret/foo" {
  capabilities = ["read"]
}

Когда эта политика назначена токену, токен может читать из “secret/foo”. Однако токен не может обновить или удалить “secret/foo”, так как возможности не позволяют этого. Поскольку политики по умолчанию запрещены, токен не будет иметь другого доступа в Stronghold.

Вот более подробная политика, и она задокументирована в строке:

# Здесь мы предоставлям полный доступ к "secret/*". Дополнительные ограничения могут быть
# применены к этой широкой политике, как показано ниже.
path "secret/*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}


# Несмотря на то, что мы разрешили secret/*, эта строка явно запрещает
# secret/super-secret. это имеет приоритет.
path "secret/super-secret" {
  capabilities = ["deny"]
}

# Политики также могут указывать разрешенные, запрещенные и обязательные параметры. здесь
# ключ "secret/restricted" может содержать только "foo" (любое значение) и "bar" (один из
# "zip" или "zap").
path "secret/restricted" {
  capabilities = ["create"]
  allowed_parameters = {
    "foo" = []
    "bar" = ["zip", "zap"]
  }
}

Политики используют сопоставление на основе пути для проверки набора возможностей по запросу. Путь политики может указывать точный путь для сопоставления или может указывать шаблон glob, который предписывает Stronghold использовать сопоставление префикса:

# Разрешить чтение только "secret/foo". Прикрепленный токен не может читать "secret/food"
# или "secret/foo/bar".
path "secret/foo" {
  capabilities = ["read"]
}

# Разрешить чтение всего под "secret/bar". Прикрепленный токен может читать
# "secret/bar/zip", "secret/bar/zip/zap", но не "secret/bars/zip".
path "secret/bar/*" {
  capabilities = ["read"]
}

# Разрешить чтение всего, что имеет префикс "zip-". Прикрепленный токен может читать
# "secret/zip-zap" или "secret/zip-zap/zong", но не "secret/zip/zap
path "secret/zip-*" {
  capabilities = ["read"]
}

Кроме того, знак + может использоваться для обозначения любого количества символов, ограниченных одним сегментом пути:

# Разрешить чтение пути "teamb" в любом пути верхнего уровня в secret/
path "secret/+/teamb" {
  capabilities = ["read"]
}

# Разрешить чтение secret/foo/bar/teamb, secret/bar/foo/teamb и т.д.
path "secret/+/+/teamb" {
  capabilities = ["read"]
}

Архитектура Stronghold похожа на файловую систему. Каждое действие в Stronghold имеет соответствующий путь и возможность — даже внутренние конечные точки конфигурации ядра Stronghold находятся под путем “sys/”. Политики определяют доступ к этим путям и возможностям, которые контролируют доступ токена к учетным данным в Stronghold.

Примечание: правила политики, применяемые Stronghold, определяются наиболее точным доступным соответствием с использованием правил приоритета, описанных ниже. Это может быть точное соответствие или соответствие с самым длинным префиксом glob. Если один и тот же шаблон появляется в нескольких политиках, мы берем объединение возможностей. Если в применимых политиках появляются разные шаблоны, мы берем только самое приоритетное соответствие из этих политик.

Это означает, что если вы определяете политику для “secret/foo*”, политика также будет соответствовать “secret/foobar”. В частности, когда потенциально существует несколько соответствующих путей политики, P1 и P2, применяются следующие критерии соответствия:

Символ glob, упомянутый в этой документации, — это звездочка (*). Это не регулярное выражение, и поддерживается только как последний символ пути!

При предоставлении возможности списка важно отметить, что поскольку список всегда работает с префиксом, политики должны работать с префиксом, поскольку Stronghold очистит пути запросов, чтобы они стали префиксами.

Возможности

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

Чтобы определить возможности, необходимые для выполнения конкретной операции, к подкоманде CLI можно добавить флаг -output-policy. В качестве примера см. раздел документа «Требования к политике печати».

Список возможностей включает следующее:

create (POST/PUT) - Позволяет создавать данные по заданному пути. Очень немногие части Stronghold проводят различие между созданием и обновлением, поэтому для большинства операций требуются возможности как создания, так и обновления.

read (GET) - Позволяет читать данные по заданному пути.

update (POST/PUT) - Позволяет изменить данные по заданному пути. В большинстве частей Stronghold это неявно включает возможность создания начального значения по данному пути.

patch (PATCH) - позволяет частично обновлять данные по заданному пути.

delete (DELETE) - позволяет удалять данные по заданному пути.

list (LIST) - позволяет перечислить значения по заданному пути. Обратите внимание, что ключи, возвращаемые операцией list, не фильтруются политиками. Не кодируйте конфиденциальную информацию в именах ключей. Не все бэкенды поддерживают перечисление.

В приведенном выше списке соответствующие HTTP-глава указаны в скобках рядом с возможностью. При составлении политики обычно полезно посмотреть документацию по HTTP API для путей и HTTP-глаголов и сопоставить их с возможностями. Хотя сопоставление не является строгим 1:1, они часто очень похожи друг на друга.

В дополнение к стандартному набору есть некоторые возможности, которые не сопоставляются с HTTP-методами.

sudo - разрешает доступ к путям, защищенным правами root. Токенам не разрешается взаимодействовать с этими путями, если у них нет возможности sudo (в дополнение к другим возможностям, необходимым для выполнения операции над этим путем, таким как чтение или удаление).

Например, для модификации бэкендов журнала аудита требуется токен с привилегиями sudo.

deny - запрещает доступ. Этот параметр всегда имеет приоритет, независимо от любых других определенных возможностей, включая sudo.

Примечание: Возможности обычно привязываются к HTTP-методу, а не к основному выполняемому действию. Это может быть частым источником путаницы. Генерация учетных данных базы данных создает учетные данные базы данных, но HTTP-запрос - это GET, что соответствует возможности чтения. Таким образом, чтобы предоставить доступ к созданию учетных данных базы данных, политика должна предоставить доступ на чтение по соответствующему пути.

Шаблонные политики

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

Параметры Имя Описание identity.entity.id Идентификатор сущности identity.entity.name Имя сущности identity.entity.metadata.<ключ метаданных=""> Метаданные, связанные с сущностью для данного ключа identity.entity.aliases..id Идентификатор псевдонима сущности для данного монтирования identity.entity.aliases..name Имя псевдонима сущности для данного крепления identity.entity.aliases..metadata. Метаданные, связанные с псевдонимом для данного монтирования и ключом метаданных identity.entity.aliases..custom_metadata. Пользовательские метаданные, связанные с псевдонимом для данного монтирования и ключом пользовательских метаданных identity.groups.ids..name Имя группы для данного идентификатора группы identity.groups.names..id Идентификатор группы для данного имени группы identity.groups.ids..metadata. Метаданные, связанные с группой для данного ключа identity.groups.names..metadata. Метаданные, связанные с группой для данного ключа

Примеры

Следующая политика создает раздел KVv2 Secret Engine для определенного пользователя

path "secret/data//*" {
  capabilities = ["create", "update", "patch", "read", "delete"]
}

path "secret/metadata//*" {
  capabilities = ["list"]
}

Если вы хотите создать общий раздел KV, связанный с сущностями, входящими в группу.

# In the example below, the group ID maps a group and the path
# В приведенном ниже примере идентификатор группы объединяет группу и путь

path "secret/data/groups//*" {
  capabilities = ["create", "update", "patch", "read", "delete"]
}

path "secret/metadata/groups//*" {
  capabilities = ["list"]
}

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

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

Получить значение аксессора монтирования можно с помощью следующей команды:

d8 stronghold auth list

Пример вывода:

Path           Type          Accessor                    Description
----           ----          --------                    -----------
kubernetes/    kubernetes    auth_kubernetes_xxxx        n/a
token/         token         auth_token_yyyy             token based credentials

Следующая шаблонная политика позволяет читать путь, связанный с пространством имен учетной записи сервиса Kubernetes идентификатора:

path "secret/data//*" {
  capabilities = ["read"]
}

Тонкий контроль

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

Ограничения на параметры

Примечание: Использование глобусов (*) может привести к неожиданному поведению.

Примечание: Поля allowed_parameters, denied_parameters и required_parameters не поддерживаются для политик, используемых с механизмом секретов kv версии 2.

Дополнительную информацию см. в спецификации API.

Политики могут учитывать параметры HTTP-запроса для дальнейшего ограничения запросов, используя следующие параметры:

required_parameters - список параметров, которые должны быть указаны.

# Это требует от пользователя создания «secret/profile» с параметром/ключом с именами
# «name» и «id», где kv v1 включен по пути «secret/».
path "secret/profile" {
  capabilities = ["create"]
  required_parameters = ["name", "id"]
}

allowed_parameters - Список ключей и значений, которые разрешены для данного пути.

Задание параметру значения из пустого списка позволяет параметру содержать любое значение.

# Это позволяет пользователю обновить значение параметра пароля, установленное для любого
# пользователей, настроенных на метод аутентификации userpass. Значение пароля может быть
# что угодно. Однако пользователь не может обновлять значения других параметров, таких как
# token_ttl.
path "auth/userpass/users/*" {
  capabilities = ["update"]
  allowed_parameters = {
    "password" = []
  }
}

Пример использования: В учебном пособии ACL Policy Path Templating демонстрируется использование allowed_parameters для разрешения пользователю обновлять пароль пользователя при использовании метода userpass auth для входа в систему Stronghold.

Установка параметра со значением из заполненного списка позволяет параметру содержать только эти значения.

# Это позволяет пользователю создать или обновить ключ шифрования для транзитного
# механизма секретов по адресу «transit/». Когда вы это сделаете, вы можете установить
# значение параметра «auto_rotate_period», чтобы ключ ротировался.
# Однако период ротации должен быть равен «8h», «24h» или «5d».
# Любое другое значение приведет к ошибке.

path "transit/keys/*" {
  capabilities = ["create", "update"]
  allowed_parameters = {
    "auto_rotate_period" = ["8h", "24h", "5d"]
  }
}

Если указаны какие-либо ключи, все не указанные параметры будут запрещены, за исключением случая, когда параметр «*» установлен в пустой массив, что позволит изменять все остальные параметры. Параметры с определенными значениями будут по-прежнему ограничены этими значениями.

# Когда механизм секретов kv v1 включен в «secret/», это позволяет пользователю
# создать «secret/foo» с параметром «bar». Параметр «bar» может
# содержать только значения «zip» или «zap», но любые другие параметры могут быть
# но любые другие параметры могут быть созданы с любым значением.
path "secret/foo" {
  capabilities = ["create"]
  allowed_parameters = {
    "bar" = ["zip", "zap"]
    "*"   = []
  }
}

denied_parameters - список ключей и значений, которые не разрешены для данного пути. Любые значения, указанные здесь, имеют приоритет над allowed_parameters.

Установка параметра со значением из пустого списка запрещает любые изменения этого параметра.

# Это позволяет пользователю обновлять пользовательские настройки метода userpass auth
# конфигурации (например, «пароль»), но не может обновлять значения параметров «token_policies»
# и значения параметров «policies».

path "auth/userpass/users/*" {
  capabilities = ["update"]
  denied_parameters = {
    "token_policies" = []
    "policies" = []
  }
}

Установка параметра со значением из заполненного списка запрещает любые параметры, содержащие эти значения.

# This allows the user to create or update token roles. However, the
# "allowed_policies" parameter value cannot be "admin", but the user can
# assign any other policies to the parameter.
path "auth/token/roles/*" {
  capabilities = ["create", "update"]
  denied_parameters = {
    "allowed_policies" = ["admin"]
  }
}

Setting to “*” will deny any parameter.

# This allows the user to create or update an encryption key for transit
# secrets engine enabled at "transit/". However, the user cannot set any of
# the configuration parameters. As a result, the created key will have all
# parameters set to default values.
path "transit/keys/*" {
  capabilities = ["create", "update"]
  denied_parameters = {
    "*" = []
  }
}

Если указаны какие-либо параметры, то все не указанные параметры разрешены, если только не задан параметр allowed_parameters, в этом случае применяются обычные правила.

Значения параметров также поддерживают сглаживание префиксов/суффиксов. Оглоблирование включается путем добавления к значению префикса или префикса (*):

# Only allow a parameter named "bar" with a value starting with "foo-*".
path "secret/foo" {
  capabilities = ["create"]
  allowed_parameters = {
    "bar" = ["foo-*"]
  }
}

Примечание: единственным значением, которое можно использовать с параметром *, является [].

Ограничения параметров

Значения по умолчанию

Оценка политик с разрешенными_параметрами, запрещенными_параметрами и требуемыми_параметрами происходит без учета значений параметров по умолчанию.

Рассмотрим следующую политику:

# The "no_store" parameter cannot be false
path "secret/foo" {
  capabilities = ["create"]
  denied_parameters = {
    "no_store" = [false, "false"]
  }
}

Следующая операция будет выполнена с ошибкой, поскольку для параметра «no_store» установлено значение false:

d8 stronghold write secret/foo no_store=false value=bar

В то время как следующая операция будет успешной, даже если параметр «no_store» должен быть булевым, а по умолчанию он равен false:

# Succeeds because "no_store=false" isn't present in the parameters
d8 stronghold write secret/foo value=bar

Это происходит потому, что анализатор политики не знает, какое значение по умолчанию имеет параметр «no_store». Все, что он видит, это то, что запрещенный параметр не присутствует в команде.

Эту проблему можно решить, потребовав в политике параметр «no_store»:

path "secret/foo" {
  capabilities = ["create"]
  required_parameters = ["no_store"]
  denied_parameters = {
    "no_store" = [false, "false"]
  }
}

Следующая команда, которая ранее была успешной, теперь не выполнится в соответствии с новой политикой, поскольку отсутствует параметр «no_store»:

d8 stronghold write secret/foo value=bar

Globbing

Также важно отметить, что использование globbing может привести к неожиданному поведению:

# This allows the user to create, update, or patch "secret/foo" with a parameter
# named "bar". the values passed to parameter "bar" must start with "baz/"
# so values like "baz/quux" are fine. however, values like
# "baz/quux,wibble,wobble,wubble" would also be accepted. the API that
# underlies "secret/foo" might allow comma delimited values for the "bar"
# parameter, and if it did, specifying a value like
# "baz/quux,wibble,wobble,wubble" would result in 4 different values getting
# passed along. seeing values like "wibble" or "wobble" getting passed to
# "secret/foo" might surprise someone that expected the allowed_parameters
# constraint to only allow values starting with "baz/".
path "secret/foo" {
  capabilities = ["create", "update", "patch"]
  allowed_parameters = {
    "bar" = ["baz/*"]
  }
}

Требуемые TTL для обертывания ответа

Эти параметры можно использовать для установки минимальных/максимальных значений TTL, задаваемых клиентами при запросе на обертывание ответа, с точностью до секунды. Они используют строки формата duration.

На практике установка минимального TTL в одну секунду делает обертку ответа обязательной для определенного пути.

min_wrapping_ttl - минимально допустимый TTL, который клиенты могут указать для обернутого ответа. На практике установка минимального TTL в одну секунду фактически делает обертку ответа обязательной для конкретного пути. Это также может использоваться для обеспечения того, чтобы TTL не было слишком низким, что приведет к тому, что конечные цели не смогут развернуть ответ до истечения срока действия маркера.

max_wrapping_ttl - Максимально допустимый TTL, который клиенты могут указать для обернутого ответа.

# This effectively makes response wrapping mandatory for this path by setting min_wrapping_ttl to 1 second.
# This also sets this path's wrapped response maximum allowed TTL to 90 seconds.
path "auth/approle/role/my-role/secret-id" {
    capabilities = ["create", "update"]
    min_wrapping_ttl = "1s"
    max_wrapping_ttl = "90s"
}

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

Встроенные политики

В Stronghold есть две встроенные политики: по умолчанию и root. В этом разделе описываются две встроенные политики.

Политика по умолчанию

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

Политика содержит базовую функциональность, такую как возможность для токена искать данные о себе и использовать данные о своих закутках. Однако Stronghold не предписывает ее содержание. Ее можно изменять в соответствии с вашими потребностями; Stronghold никогда не перезапишет ваши изменения. Если вы хотите быть в курсе последних версий политики по умолчанию, просто прочитайте ее содержимое с актуального dev-сервера и запишите его в политику по умолчанию вашего Stronghold.

Чтобы просмотреть все разрешения, предоставленные политикой по умолчанию для вашей установки Stronghold, выполните команду:

d8 stronghold read sys/policy/default

Чтобы отключить прикрепление политики по умолчанию:

d8 stronghold token create -no-default-policy

или через API:

curl \
  --request POST \
  --header "X-Vault-Token: ..." \
  --data '{"no_default_policy": "true"}' \
  https://stronghold.example.com/v1/auth/token/create

Корневая политика

Корневая (root) политика - это встроенная политика Stronghold, которую нельзя изменить или удалить. Любой пользователь, связанный с этой политикой, становится root пользователем. Пользователь root может делать все, что угодно в Stronghold. Поэтому настоятельно рекомендуется отозвать все root-токены перед началом эксплуатации Stronghold.

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

Чтобы отозвать root токен, выполните команду:

d8 stronghold token revoke "<token>"

или через API:

curl \
  --request POST \
  --header "X-Vault-Token: ..." \
  --data '{"token": "<token>"}' \
  https://stronghold.example.com/v1/auth/token/revoke

Управление политиками

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

Список политик

Чтобы вывести список всех зарегистрированных политик в Stronghold:

d8 stronghold read sys/policy

или через API:

curl \
  --header "X-Vault-Token: ..." \
  https://stronghold.example.com/v1/sys/policy

Создание политик

Политики могут быть созданы через CLI или через API. Чтобы создать новую политику в Stronghold:

d8 stronghold policy write policy-name policy-file.hcl

или через API:

curl \
  --request POST \
  --header "X-Vault-Token: ..." \
  --data '{"policy":"path \"...\" {...} "}' \
  https://stronghold.example.com/v1/sys/policy/policy-name

В обоих примерах имя политики - «policy-name». Это имя можно рассматривать как указатель или симлинк на ACL политики. Токены прикрепляются к политике по имени, которое затем сопоставляется с набором правил, соответствующих этому имени.

Обновление политик

Существующие политики могут быть обновлены для изменения разрешений через CLI или API. Чтобы обновить существующую политику в Stronghold, выполните те же действия, что и при создании политики, но используйте имя существующей политики:

d8 stronghold write sys/policy/my-existing-policy policy=@updated-policy.json

или через API:

curl \
  --request POST \
  --header "X-Vault-Token: ..." \
  --data '{"policy":"path \"...\" {...} "}' \
  https://stronghold.example.com/v1/sys/policy/my-existing-policy

Удаление политик Существующие политики можно удалить с помощью CLI или API. Чтобы удалить политику:

d8 stronghold delete sys/policy/policy-name

или через API:

curl \
  --request DELETE \
  --header "X-Vault-Token: ..." \
  https://stronghold.example.com/v1/sys/policy/policy-name

Это идемпотентная операция. Stronghold не вернет ошибку при удалении несуществующей политики.

Ассоциирование политик

Stronghold может автоматически ассоциировать набор политик с токеном на основе авторизации. Эта конфигурация существенно различается в разных бэкендах аутентификации. Для простоты в этом примере будет использован встроенный в Stronghold метод аутентификации userpass.

Администратор или кто-то из команды безопасности создаст пользователя со списком связанных политик:

d8 stronghold write auth/userpass/users/sethvargo \
    password="s3cr3t!" \
    policies="dev-readonly,logs"

Это создает сопоставление аутентификации с политикой, так что при успешной аутентификации пользователя в Stronghold ему выдается токен со списком политик.

Пользователь, желающий пройти аутентификацию, должен выполнить команду

$ d8 stronghold login -method="userpass" username="sethvargo"
Password (will be hidden): ...

Если предоставленная информация верна, Stronghold сгенерирует токен, присвоит ему список настроенных политик и вернет этот токен аутентифицированному пользователю.

Конечные точки API с корневой защитой

Примечание: Stronghold рассматривает глаголы HTTP POST и PUT как эквивалентные, поэтому для каждого упоминания POST в таблице выше может также использоваться PUT. Stronghold использует нестандартный HTTP-глагол LIST, но также позволяет делать запросы к списку с помощью глагола GET и параметра запроса ?list=true, поэтому для каждого упоминания LIST в таблице выше можно также использовать GET с ?list=true.

Следующие пути требуют наличия в политике токена root или права sudo:

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

Токены ассоциируются со своими политиками во время создания. Например:

d8 stronghold token create -policy=dev-readonly -policy=logs

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

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

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