Метод Approle

Метод AppRole

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

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

d8 stronghold auth enable approle

stronghold auth enable approle

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

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

d8 stronghold auth enable -path=my-login approle

stronghold auth enable -path=my-login approle

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

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

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

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

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

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

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

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]

$ 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

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

d8 stronghold auth enable approle

stronghold auth enable approle

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

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

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.

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

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

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

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 может оставаться скрытым от всех, кроме самого клиента, с помощью механизма обёртывания ответа.

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

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

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

Дополнительные ресурсы

• Приложение на виртуальной машине со Stronghold Agent
• CI/CD
• TLS-сертификат для веб-сервера на ВМ из PKI Stronghold
• Примеры использования