Методы аутентификации

Методы аутентификации это модули Stronghold, которые в рамках обработки запроса в хранилище идентифицируют пользователя, выполняют аутентификацию и отвечают за назначение идентичности и набора политик пользователю. В большинстве случаев Stronghold будет делегировать управление аутентификацией и принятие решений соответствующему настроенному внешнему методу аутентификации, таким, как JWT, OIDC, Kubernetes и LDAP. В качестве источников данных о пользователях с помощью указанных методов могут использоваться кластера Deckhouse Kubernetes Platform, Keycloak, Blitz Identity Provider, Active Directory и т.д. Наличие нескольких методов аутентификации позволяет вам использовать тот метод, который наиболее подходит для вашего использования Stronghold и вашей организации. Возможно использование нескольких методов аутентификации одновременно.

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

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

Включение/отключение методов аутентификации на примере AppRole

Методы аутентификации могут быть включены и отключены с помощью UI, CLI или API.

Включение с помощью CLI:

vault auth enable approle

При включении методы аутентификации аналогичны механизмам секретов: они монтируются в таблицу монтирования Stronghold и могут быть доступны и настраиваться с использованием стандартного API для чтения/записи. Все методы аутентификации по умолчанию монтируются в поддиректории auth/ и выглядят как auth/, например auth/oidc/.

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

vault auth enable -path=my-login approle

Включение с помощью UI: Включение метода аутентификации

Выберите метод аутентификации: Выбор метода аутентификации

Настройте и подтвердите включение метода аутентификации: Настройка и подтверждение метода аутентификации

Для отключения метода аутентификации выберите метод: Выбор метода аутентификации

Подтвердите удаление метода: Подтверждение удаление метода

Метод аутентификации AppRole

Метод аутентификации approle позволяет машинам или приложениям аутентифицироваться с помощью определенных в Stronghold ролей. Открытый дизайн AppRole позволяет использовать различные рабочие процессы и конфигурации для обработки большого количества приложений. Этот метод аутентификации ориентирован на автоматизированные рабочие процессы. Мы рекомендуем использовать batch токены с методом аутентификации AppRole.

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

Аутентификация с помощью CLI

Путь по умолчанию - /approle. Если этот метод аутентификации был включен по другому пути, укажите нужный путь вместо пути по умолчанию.

vault write auth/approle/login \
  role_id=db02de05-fa49-4055-059b-67221c5c2f63 \
  secret_id=6a174c20-f6de-a63c-74d2-6018fcceff64

Key                Value
---                -----
token              75b74ffd-842c-fd43-1386-f7d7006e520a
token_accessor     4c29bc22-5c72-11a6-f778-2bc8f48cea0e
token_duration     20m0s
token_renewable    true
token_policies     [default]

Аутентификация с помощью API

Путь по умолчанию - auth/approle/login. При использовании другого пути, укажите нужный путь вместо пути по умолчанию.

Пример запроса:

curl \
  --header "X-Vault-Token: ${VAULT_TOKEN}" \
  --request POST \
  --data '{"role_id":"988a9df-...","secret_id":"37b74931..."}' \
  ${VAULT_ADDR}/v1/auth/approle/login

Ответ API будет содержать токен в качестве значения auth.client_token:

{
  "auth": {
    "renewable": true,
    "lease_duration": 2764800,
    "metadata": {},
    "policies": ["default", "dev-policy", "test-policy"],
    "accessor": "5d7fb475-07cb-4060-c2de-1ca3fcbf0c56",
    "client_token": "98a4c7ab-b1fe-361b-ba0b-e307aacfd587"
  }
}

-> Application Integration: See the Code Example section for a code snippet demonstrating the authentication with Vault using the AppRole auth method.

Конфигурирование

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

Конфигурирование через CLI

  1. Включите метод аутентификации AppRole:
vault auth enable approle
  1. Создайте именованную роль:
vault write auth/approle/role/my-role \
  token_type=batch \
  secret_id_ttl=10m \
  token_num_uses=10 \
  token_ttl=20m \
  token_max_ttl=30m \
  secret_id_num_uses=40

Примечание: Если токен, выданный вашим approle, требует возможности создания дочерних токенов, вам необходимо установить значение token_num_uses равным 0.

Для полного списка параметров конфигурации, пожалуйста, ознакомьтесь с API документацией.

  1. Получите RoleID для AppRole:

    vault read auth/approle/role/my-role/role-id
  role_id     db02de05-fa49-4055-059b-67221c5c2f63

  2. Получите SecretID, выданный для AppRole:

vault write -f auth/approle/role/my-role/secret-id
  secret_id               6a174c20-f6de-a63c-74d2-6018fcceff64
  secret_id_accessor      c454f7e5-996e-7230-6074-6ef26b7bcf86
  secret_id_ttl           10m
  secret_id_num_uses      40

Конфигурирование через API

  1. Включение метода аутентификации AppRole:
curl \
  --header "X-Vault-Token: ${VAULT_TOKEN}" \
  --request POST \
  --data '{"type": "approle"}' \
  ${VAULT_ADDR}/v1/sys/auth/approle
  1. Создайте AppRole с необходимым набором политик:
curl \
  --header "X-Vault-Token: ${VAULT_TOKEN}" \

  --data '{"policies": "dev-policy,test-policy", "token_type": "batch"}' \
  ${VAULT_ADDR}/v1/auth/approle/role/my-role
  1. Получите идентификатор роли:
curl \
  --header "X-Vault-Token: ${VAULT_TOKEN}" \
  ${VAULT_ADDR}/v1/auth/approle/role/my-role/role-id

Пример ответа API:

{
  "data": {
  "role_id": "888a9dfd-ea69-4a53-6cb6-9d6b86474bba"
  }
}
  1. Создайте новый идентификатор секрета для роли:
curl \
  --header "X-Vault-Token: ${VAULT_TOKEN}" \
  --request POST \
  ${VAULT_ADDR}/v1/auth/approle/role/my-role/secret-id

Пример ответа API:

{
  "data": {
    "secret_id_accessor": "65946873-1d96-a9d4-678c-9229f74386a5",
    "secret_id": "37b24931-c4cd-d49a-9246-ccc62d682a25",
    "secret_id_ttl": 600,
    "secret_id_num_uses": 40
  }
}

Учетные данные/Ограничения

RoleID

RoleID - это идентификатор, который выбирает AppRole, по которому оцениваются другие учетные данные. При аутентификации с использованием конечной точки входа этого метода аутентификации, RoleID является обязательным аргументом (через role_id) всегда. По умолчанию RoleID являются уникальными UUID, что позволяет им служить вторичными секретами для другой информации об учетных данных. Однако они могут быть установлены на определенные значения для сопоставления с информацией, полученной клиентом (например, доменное имя клиента).

SecretID

SecretID - это учетные данные, которые по умолчанию требуются для любого входа (через secret_id) и всегда должны быть секретными. (Для расширенного использования требование SecretID может быть отключено с помощью параметра bind_secret_id AppRole, позволяя машинам, знающим только RoleID или соответствующие другие ограничения, получить токен). SecretID может быть создан для AppRole либо путем генерации 128-битного полностью случайного UUID самим ролью (Pull режим), либо путем указания определенных пользовательских значений (Push режим). Аналогично токенам, у SecretID есть свойства, такие как ограничение использования, TTL и сроки действия.

Режимы Pull и Push SecretID

Если SecretID, используемый для входа, извлекается из AppRole, это работает в режиме Pull. Если клиент устанавливает “пользовательский” SecretID для AppRole, это называется режимом Push. Режим Push имитирует поведение устаревшего метода аутентификации App-ID; однако в большинстве случаев режим Pull является более предпочтительным подходом. Причина в том, что режим Push требует, чтобы некая другая система знала полный набор учетных данных клиента (RoleID и SecretID), чтобы создать запись, даже если они затем распространяются по разным путям. Однако в режиме Pull, хотя RoleID должен быть известен для его распространения клиенту, SecretID может быть сохранен в тайне от всех сторон, кроме конечного аутентифицирующего клиента с использованием Response Wrapping.

Режим Push доступен для совместимости с рабочим процессом App-ID, который в некоторых конкретных случаях предпочтителен, но в большинстве случаев режим Pull является более безопасным и предпочтительным.

Дополнительные ограничения

role_id - это обязательные учетные данные на конечной точке входа. AppRole, на который указывает role_id, будет иметь настроенные ограничения. Это определяет другие required учетные данные для входа. Ограничение bind_secret_id требует представления secret_id на конечной точке входа. В будущем этот метод аутентификации может поддерживать больше параметров ограничений для поддержки различных наборов приложений. Некоторые ограничения не потребуют учетных данных, но все равно будут применять ограничения для входа. Например, secret_id_bound_cidrs позволит только входы, приходящие с IP-адресов, принадлежащих настроенным CIDR-блокам на AppRole.

API

У метода аутентификации AppRole есть полный HTTP API. Пожалуйста, ознакомьтесь с API документацией.

Метод аутентификации JWT/OIDC

Метод jwt auth может быть использован для аутентификации в Deckhouse Stronghold с помощью OIDC или путем предоставления JWT.

Метод OIDC позволяет выполнять аутентификацию через настроенный провайдер OIDC с помощью веб-браузера пользователя. Этот метод может быть инициирован из пользовательского интерфейса Deckhouse Stronghold или из командной строки. В качестве альтернативы может быть предоставлен непосредственно JWT. JWT криптографически проверяется с помощью локально предоставленных ключей, либо, если настроен, для получения соответствующих ключей может быть использован сервис OIDC Discovery. Выбор метода настраивается для каждой роли.

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

Аутентификация в OIDC

В данном разделе рассматривается настройка и использование ролей OIDC. Предполагается базовое знакомство с концепциями OIDC. Поток Authorization Code использует расширение Proof Key for Code Exchange (PKCE).

Deckhouse Stronghold включает два встроенных потока авторизации OIDC: пользовательский интерфейс Deckhouse Stronghold UI и CLI с использованием логина vault.

Перенаправление URI

Важной частью конфигурации ролей OIDC является правильная настройка URI перенаправления. Это должно быть сделано как в Deckhouse Stronghold, так и в провайдере OIDC, причем эти настройки должны совпадать. URI перенаправления задаются для роли с помощью параметра allowed_redirect_uris. Для настройки потоков Deckhouse Stronghold UI и CLI существуют различные URI перенаправления, поэтому в зависимости от установки необходимо настроить один или оба.

CLI

Если планируется поддержка аутентификации через vault login -method=oidc, необходимо задать URI перенаправления на localhost. Обычно это может быть: http://localhost:8250/oidc/callback. При необходимости при входе в систему через CLI можно указать другой хост и/или порт прослушивания, при этом URI с этим хостом/портом должен совпадать с одним из настроенных перенаправляемых URI. Эти же URI “localhost” должны быть добавлены и в провайдер.

Deckhouse Stronghold UI

Для входа в систему через Deckhouse Stronghold сам UI не требует настройки и конфигурируется автоматически при включении Deckhouse Stronghold

Вход в систему OIDC (Deckhouse Stronghold UI)

Выберите метод входа в систему “OIDC”.

При необходимости введите имя роли.

Нажмите кнопку “Войти с помощью провайдера OIDC” и завершите аутентификацию с помощью настроенного провайдера.

Вход в систему OIDC (CLI)

Для входа в систему CLI по умолчанию используется путь /oidc_deckhouse. Если данный метод аутентификации был включен по другому пути, укажите в CLI путь -path=/my-path.

vault login -method=oidc -path=oidc_deckhouse role=test
Complete the login via your OIDC provider. Launching browser to:
https://myco.auth0.com/authorize?redirect_uri=http%3A%2F%2Flocalhost%3A8400%2Foidc%2Fcallback&client_id=r3qXc2bix9eF...

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

Автоматический запуск браузера по умолчанию на URL переключается при помощи skip_browser (по умолчанию: “false”) при входе в систему.

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

  • mount (по умолчанию “oidc”)
  • listenaddress (по умолчанию “localhost”)
  • port (по умолчанию 8250)
  • callbackhost (по умолчанию “localhost”)
  • callbackmethod (по умолчанию “http”)
  • callbackport (по умолчанию - это значение, заданное для порта). Это значение используется в параметре redirect_uri, тогда как port - это порт сервера localhost, который принимает запросы. В некоторых случаях эти два параметра могут различаться.
Конфигурация провайдера OIDC

Способ аутентификации OIDC успешно протестирован с рядом провайдеров. Полное руководство по настройке приложений OAuth/OIDC не входит в документацию Deckhouse Stronghold.

Устранение неполадок в конфигурации OIDC

Некоторые советы по настройке OIDC представлены ниже:

  • Если параметр роли (например, bound_claims) требует значения карты (map), его нельзя установить отдельно с помощью Deckhouse Stronghold CLI. В таких случаях запишите конфигурацию в виде одного JSON-объекта:

    vault write auth/oidc/role/demo -<<EOF
{
"user_claim": "sub",
"bound_audiences": "abc123",
"role_type": "oidc",
"policies": "demo",
"ttl": "1h",
"bound_claims": { "groups": ["mygroup/mysubgroup"] }
}
EOF

  • Проследите за выводом журнала Deckhouse Stronghold, в котором содержится важная информация о сбоях проверки OIDC.

  • Убедитесь, что URI перенаправления корректны в Deckhouse Stronghold и на провайдере. Они должны точно совпадать. Проверьте: http/https, 127.0.0.1/localhost, номера портов, наличие слэшей в конце.

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

  • bound_audiences не является обязательным для ролей OIDC и обычно не требуется. Идентификаторы клиентов OIDC используют client_id для определения аудитории, и проверка OIDC предполагает это.

  • Уточните у провайдера диапазоны для получения необходимой информации. Часто требуется запрашивать диапазоны “профиль” и “группы”, которые можно добавить, установив для роли значение oidc_scopes="profile,groups".

  • Если в журналах появляются ошибки, связанные с заявками, внимательно изучите документацию поставщика, чтобы понять, как он называет и структурирует заявки. В зависимости от провайдера, сконструируйте простой запрос curl implicit grant для получения JWT, который можно просмотреть.

Пример декодирования JWT (в примере он расположен в поле access_token JSON-ответа) представлен ниже:

cat jwt.json | jq -r .access_token | cut -d. -f2 | base64 -D
  • В Deckhouse Stronghold доступна ролевая опция verbose_oidc_logging, которая будет записывать полученный OIDC-токен в журналы сервера, если включено ведение журнала на уровне отладки. Это может быть полезно при отладке настройки провайдера и проверке того, что полученные претензии соответствуют ожиданиям. Поскольку данные утверждений записываются в журнал дословно и могут содержать конфиденциальную информацию, эту опцию не следует использовать в производстве.

Аутентификация по JWT

Способ аутентификации для ролей типа “jwt” проще, чем в OIDC, поскольку Deckhouse Stronghold требуется только проверить предоставленный JWT.

Проверка JWT

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

  • Статические ключи. Набор открытых ключей хранится в конфигурации бэкенда.
  • JWKS. Настраивается URL-адрес JSON Web Key Set (JWKS) (и дополнительная цепочка сертификатов). Ключи извлекаются из конечной точки при аутентификации.
  • OIDC Discovery. Настраивается URL-адрес OIDC Discovery (и необязательная цепочка сертификатов). Ключи извлекаются из URL при аутентификации. Когда используются OIDC Discovery, то применяются критерии проверки OIDC (например, iss, aud и т.д.).

Если необходимо использовать несколько методов, можно установить и сконфигурировать другой экземпляр бэкенда.

Аутентификация JWT через CLI
vault write auth/<path-to-jwt-backend>/login role=demo jwt=...

Путь по умолчанию для бэкенда аутентификации JWT - /jwt, поэтому если вы используете бэкенд по умолчанию, то команда будет выглядеть так:

vault write auth/jwt/login role=demo jwt=...

Если бэкенд JWT auth использует другой путь, используйте его.

Аутентификация JWT через API

По умолчанию используется конечная точка auth/jwt/login. Если этот метод аутентификации был включен по другому пути, используйте это значение вместо jwt, как представлено на примере ниже:

curl \
  --request POST \
  --data '{"jwt": "your_jwt", "role": "demo"}' \
  http://127.0.0.1:8200/v1/auth/jwt/login

В ответе, который представлен ниже, будет содержаться токен по адресу auth.client_token:

{
  "auth": {
    "client_token": "38fe9691-e623-7238-f618-c94d4e7bc674",
    "accessor": "78e87a38-84ed-2692-538f-ca8b9f400ab3",
    "policies": ["default"],
    "metadata": {
      "role": "demo"
    },
    "lease_duration": 2764800,
    "renewable": true
  }
}

Конфигурация

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

  1. Включите метод аутентификации JWT. Можно выбрать имя jwt или oidc. Бэкэнд будет монтироваться по выбранному имени.

    vault auth enable jwt
or
vault auth enable oidc

  2. Для настройки Deckhouse Stronghold используйте конечную точку /config. Для поддержки ролей JWT необходимо наличие локальных ключей, URL JWKS или URL OIDC Discovery. Для ролей OIDC необходимо наличие OIDC Discovery URL, OIDC Client ID и OIDC Client Secret.

    vault write auth/jwt/config \
   oidc_discovery_url="https://myco.auth0.com/" \
   oidc_client_id="m5i8bj3iofytj" \
   oidc_client_secret="f4ubv72nfiu23hnsj" \
   default_role="demo"

    Если необходимо выполнить проверку JWT с помощью валидации JWT-токена, оставьте oidc_client_id и oidc_client_secret пустыми.

    vault write auth/jwt/config \
   oidc_discovery_url="https://MYDOMAIN.eu.auth0.com/" \
   oidc_client_id="" \
   oidc_client_secret=""

  3. Создайте именованную роль:

    vault write auth/jwt/role/demo \
   allowed_redirect_uris="http://localhost:8250/oidc/callback" \
   bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
   bound_audiences="https://vault.plugin.auth.jwt.test" \
   user_claim="https://vault/user" \
   groups_claim="https://vault/groups" \
   policies=webapps \
   ttl=1h

    Эта роль авторизует JWT с заданными утверждениями subject и audience, задает политику webapps и использует заданные утверждения user/groups для настройки псевдонимов Identity.

Связанные параметры

После того как JWT подтвержден, как правильно подписанный, без истекшего срока хранения, поток авторизации проверяет соответствие всех настроенных “связанных” параметров. В некоторых случаях существуют специальные параметры, например, bound_subject, которые должны совпадать с параметром sub в JWT. Роль также может настраиваться на проверку произвольных утверждений с помощью карты (map) bound_claims. Карта содержит набор утверждений и их необходимых значений. Например, параметр bound_claims может иметь следующее значение:

{
   "division": "Europe",
   "department": "Engineering"
}

Будут авторизованы только JWT, содержащие утверждения division и department, и соответствующие им значения Europe и Engineering. Если значение представляет собой список, то утверждение должно соответствовать одному из элементов списка. Чтобы ограничить авторизацию набором адресов электронной почты используйте следующее:

{
   "email": ["fred@example.com", "julie@example.com"]
}

Связанные формулы могут быть опционально сконфигурированы с помощью globes. Globe - это определение шаблонов в тексте, которые могут быть заменены при выполнении операции. Например, если у пользователя есть glob *.conf, то при выполнении операции с этим glob все файлы с расширением .conf будут обработаны. Это полезно при автоматизации процессов, связанных с обработкой файлов.

Утверждения как метаданные

Данные из утверждений могут быть скопированы в результирующие метаданные токена аутентификации и псевдонима (alias) с помощью настройки claim_mappings. Этот параметр роли представляет собой карту элементов для копирования. Элементы карты имеют вид: “<JWT claim>”:"<metadata key>". Предположим, что параметр claim_mappings имеет значение:

{
   "division": "organization",
   "department": "department"
}

Это указывает, что значение JWT-требования division должно копироваться в ключ метаданных organization. Значение утверждения JWT department также копируется в метаданные, но при этом сохраняется имя ключа. Если утверждение сконфигурировано в claim_mappings, то должно существовать и в JWT, иначе аутентификация завершится неудачей.

Примечание: имя ключа метаданных “role” зарезервировано и не может быть использовано для сопоставления утверждений.

Спецификации утверждений и JSON-указатель

Некоторые параметры (например, bound_claims, groups_claim, claim_mappings, user_claim) используются для указания на данные в JWT. Если нужный ключ находится на верхнем уровне JWT, то имя ключа может быть указано напрямую. Если же он вложен на более низком уровне, то можно использовать JSON-указатель.

Предположим, что необходимо сослаться на следующие JSON-данные:

{
   "division": "North America",
   "groups": {
      "primary": "Engineering",
      "secondary": "Software"
   }
}

Параметр division будет ссылаться на North America, поскольку это ключ верхнего уровня. Параметр /groups/primary использует синтаксис JSON Pointer для ссылки на Engineering на более низком уровне. В качестве селектора может быть использован любой допустимый указатель JSON Pointer.

Метод аутентификации по токену (Token auth)

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

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

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

Аутентификация

Через CLI

В этом примере пользователь выполняет вход в систему vault, используя токен:

vault login token=<token>

В следующем примере пользователь выполняет вход в систему vault с использованием метода аутентификации userpass. Пользователь вводит свои учетные данные в формате username=значение и password=значение.

vault login -method=userpass \
   username=mitchellh \
   password=foo

Через API

Токен задается непосредственно в виде заголовка для HTTP API. Заголовок должен иметь вид X-Vault-Token: <token> или Authorization: Bearer <token>.

curl \
   --request POST \
   --data '{"password": "foo"}' \
   http://127.0.0.1:8200/v1/auth/userpass/login/mitchellh

В ответе будет содержаться токен по адресу auth.client_token, как представлено ниже в примере:

{
   "lease_id": "",
   "renewable": false,
   "lease_duration": 0,
   "data": null,
   "auth": {
      "client_token": "c4f280f6-fdb2-18eb-89d3-589e2e834cdb",
      "policies": ["admins"],
      "metadata": {
         "username": "mitchellh"
      },
      "lease_duration": 0,
      "renewable": false
   }
}

Метод аутентификации по логину/паролю (Userpass auth)

Метод авторизации userpass позволяет пользователям проходить аутентификацию в Deckhouse Stronghold с помощью комбинации имени пользователя и пароля.

Комбинации имени пользователя и пароля конфигурируются непосредственно в методе auth с помощью пути users/. Этот метод не может считывать имена пользователей и пароли из внешнего источника.

Все вводимые имена пользователей записываются в нижнем регистре, например, Mary и mary - это одна и та же запись.

Конфигурация

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

  1. Включите метод аутентификации userpass, как представлено ниже:

    vault auth enable userpass

    Это позволяет включить метод аутентификации userpass по адресу auth/userpass. Чтобы включить его по другому пути, используйте флаг -path, как представлено ниже:

    vault auth enable -path=<path> userpass

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

    vault write auth/<userpass:path>/users/mitchellh \
   password=foo \
   policies=admins

В результате создается новый пользователь mitchellh с паролем foo, который будет связан с политикой admins. Это единственная необходимая конфигурация.