Метод Approle

Метод AppRole

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

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

d8 stronghold auth enable approle

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

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

d8 stronghold auth enable -path=my-login approle

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

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

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

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

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

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

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

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

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

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

d8 stronghold 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: ${STRONGHOLD_TOKEN}" \
  --request POST \
  --data '{"role_id":"988a9df-...","secret_id":"37b74931..."}' \
  ${STRONGHOLD_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"
  }
}

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

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

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

Включите метод аутентификации AppRole:

d8 stronghold auth enable approle

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

d8 stronghold 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 документацией.

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

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

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

d8 stronghold 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

Включение метода аутентификации AppRole:

curl \
 --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" \
 --request POST \
 --data '{"type": "approle"}' \
 ${STRONGHOLD_ADDR}/v1/sys/auth/approle

Создайте AppRole с необходимым набором политик:

curl \
 --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" \

 --data '{"policies": "dev-policy,test-policy", "token_type": "batch"}' \
 ${STRONGHOLD_ADDR}/v1/auth/approle/role/my-role

Получите идентификатор роли:

curl \
 --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" \
 ${STRONGHOLD_ADDR}/v1/auth/approle/role/my-role/role-id

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

{
 "data": {
 "role_id": "888a9dfd-ea69-4a53-6cb6-9d6b86474bba"
 }
}

Создайте новый идентификатор секрета для роли:

curl \
 --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" \
 --request POST \
 ${STRONGHOLD_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) и всегда должны оставаться секретными. (Для расширенного использования это требование можно отключить, используя параметр 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, будет иметь установленные ограничения, определяющие другие обязательные учетные данные для входа. Ограничение bind_secret_id требует предоставления secret_id на конечной точке входа. В будущем этот метод аутентификации может поддерживать больше параметров ограничений для различных наборов приложений. Некоторые ограничения не потребуют учетных данных, но все равно будут накладывать ограничения на процесс входа. Например, secret_id_bound_cidrs позволит вход только с IP-адресов, связанных с определенными CIDR-блоками, настроенными в AppRole.

Метод Approle