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

Движки секретов. LDAP (API)

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

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

Документация предполагает, что секретный движок LDAP включен по пути /ldap в StarVault. Поскольку можно монтировать секретные движки по любому пути, пожалуйста, обновите ваши вызовы API соответственно.

1. Управление конфигурацией

Этот конечный пункт настраивает секретный движок LDAP для управления записями пользователей.

Метод Путь

POST

/ldap/config

GET

/ldap/config

DELETE

/ldap/config

Запись LDAP, используемая для config, должна иметь необходимые права для поиска и изменения паролей записей в LDAP.

1.1. Параметры

  • binddn (string: <обязательный>) - уникальное имя (DN) объекта для связи для управления записями пользователей. Например, cn=starvault,ou=Users,dc=starvault,dc=com.

  • bindpass (string: <обязательный>) - пароль, используемый вместе с binddn для управления записями пользователей.

  • url (string: "ldap://127.0.0.1") - LDAP сервер для подключения. Примеры: ldaps://ldap.myorg.com, ldaps://ldap.myorg.com:636. Это также может быть список URL, разделённых запятыми, например, ldaps://ldap.myorg.com, ldaps://ldap.myorg.com:636, в этом случае серверы будут пытаться соединиться в порядке, если произойдут ошибки во время подключения.

  • password_policy (string: <опционально>) - имя политики паролей для генерации паролей. Обратите внимание, что это принимает имя политики, а не саму политику.

  • schema (string: "openldap") - LDAP схема для хранения паролей записей. Доступные схемы включают openldap, ad и racf.

  • userdn (string: <опционально>) - базовое DN, под которым выполняется поиск пользователя в управлении библиотеками и статических ролях. Например, ou=Users,dc=starvault,dc=com.

  • userattr (string: <опционально>) - имя поля атрибута, используемое для выполнения поиска пользователя в управлении библиотеками и статических ролях.

    По умолчанию для схемы openldap используется cn, для схемы ad используется userPrincipalName, и для схемы racf используется racfid.

  • upndomain (string: <опционально>) - домен (userPrincipalDomain), используемый для формирования строки UPN для аутентификации. Сформированная строка UPN будет представлена как [binddn]@[upndomain]. Например, если upndomain=example.com и binddn=admin, то строка UPN admin@example.com будет использоваться для входа в Active Directory.

  • connection_timeout (integer: 30 или string: "30s") - тайм-аут в секундах при попытке подключения к LDAP серверу перед попыткой следующего URL в конфигурации.

  • request_timeout (integer: 90, string: "90s" <опционально>) - тайм-аут в секундах для соединения при выполнении запросов к серверу перед возвратом ошибки.

  • starttls (bool: <опционально>) - если true, выдает команду StartTLS после установления незашифрованного соединения.

  • insecure_tls (bool: <опционально>) - если true, пропускает проверку SSL сертификата LDAP сервера - небезопасно, использовать с осторожностью!

  • certificate (string: <опционально>) - сертификат CA для использования при проверке сертификата LDAP сервера, должен быть закодирован в x509 PEM.

  • client_tls_cert (string: <опционально>) - клиентский сертификат, предоставляемый LDAP серверу, должен быть x509 закодирован в PEM.

  • client_tls_key (string: <опционально>) - клиентский ключ, предоставляемый LDAP серверу, должен быть x509 PEM закодирован.

Устаревшие параметры:

  • length (int: 64) - длина генерируемых строк паролей. Обратите внимание: некоторые схемы могут требовать более короткой длины пароля (такие как racf). Взаимно исключается с password_policy.

Замечание о генерации паролей:

length и password_policy не могут быть установлены одновременно в конфигурации. Конечная точка POST отклонит конфигурацию, если оба заданы.

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

  • Если установлено length, используется тот же алгоритм, но с указанной длиной вместо длины по умолчанию.

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

Пример тела запроса:
{
  "binddn": "cn=starvault,ou=Users,dc=starvault,dc=com",
  "bindpass": "pa$$w0rd",
  "url": "ldaps://127.0.0.11"
}
Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/config
Пример GET запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    https://127.0.0.1:8200/v1/ldap/config
Пример ответа:
{
  "data": {
    "binddn": "cn=admin,dc=starvault,dc=com",
    "case_sensitive_names": false,
    "certificate": "",
    "insecure_tls": false,
    "length": 64,
    "schema": "openldap",
    "starttls": false,
    "tls_max_version": "tls12",
    "tls_min_version": "tls12",
    "url": "ldap://127.0.0.1"
  }
}

2. Поворот корневого пароля

Конечная точка rotate-root предлагает поворот пароля для записи binddn, используемой для управления LDAP. Этот сгенерированный пароль будет известен только StarVault и не будет доступен для получения после поворота.

Метод Путь

POST

/ldap/rotate-root
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    http://127.0.0.1:8200/v1/ldap/rotate-root

3. Статические роли

Конечная точка static-role настраивает StarVault для управления паролями существующих индивидуальных LDAP записей.

Метод Путь

GET

/ldap/static-role

GET

/ldap/static-role/:role_name

POST

/ldap/static-role/:role_name

DELETE

/ldap/static-role/:role_name

3.1. Параметры

  • username (string: <обязательный>) - имя пользователя существующей LDAP записи, для которой необходимо управлять ротацией паролей. Поиск LDAP по имени пользователя будет осуществляться на основе userdn конфигурационного значения. Атрибут, который будет использоваться при поиске пользователя, можно настроить с помощью значения userattr конфигурации. Это полезно, когда dn не используется для входа (например, SSH). Не может быть изменено после создания.

    Пример: "bob"

  • dn (string: <опционально>) - уникальное имя (DN) существующей LDAP записи, для которой необходимо управлять ротацией паролей. Если задано, оно будет иметь приоритет над username для поиска LDAP, выполняемого во время ротации паролей. Не может быть изменено после создания.

    Пример: cn=bob,ou=Users,dc=starvault,dc=com

  • rotation_period (string: <обязательный>) - как часто StarVault должен ротировать пароль записи пользователя. Принимает строки формата продолжительности. Минимальный период ротации - 5 секунд.

    Пример: "3600", "5s", "1h"

Пример тела запроса:
{
  "dn": "cn=starvault,ou=Users,dc=starvault,dc=com",
  "rotation_period": "24h",
  "username": "starvault"
}
Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/static-role/starvault
Пример GET запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    http://127.0.0.1:8200/v1/ldap/static-role/starvault
Пример GET ответа:
{
  "data": {
    "dn": "uid=starvault,ou=Users,dc=starvault,dc=com",
    "last_vault_rotation": "2025-08-02T11:31:53.7812-05:00",
    "rotation_period": 86400,
    "username": "starvault"
  }
}
Пример LIST ответа:
["starvault", "bob"]

4. Пароли статической роли

Конечная точка static-cred предлагает информацию о учетных данных для данной статической роли.

Метод Путь

GET

/ldap/static-cred/:role_name
Пример get запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    http://127.0.0.1:8200/v1/ldap/static-cred/starvault
Пример get ответа:
{
  "dn": "uid=starvault,ou=Users,dc=starvault,dc=com",
  "last_vault_rotation": "2025-08-02T11:31:53.7812-05:00",
  "password": "LTNfyn7pS7XEZIxEYQ2sEAWic02PEP7zSvIs0xMqIjaU0ORzLhKOKVmYLxL1Xkyv",
  "last_password": "?@09AZSen9TzUwK7ZhafS7B0GuWGraQjfWEna5SwnmF/tVaKFqjXhhGV/Z0v/pBJ",
  "rotation_period": 86400,
  "ttl": 86072,
  "username": "starvault"
}

5. Ручная ротация пароля статической роли

Конечная точка rotate-role поворачивает пароль существующей статической роли.

Метод Путь

POST

/ldap/rotate-role/:role_name
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    http://127.0.0.1:8200/v1/ldap/rotate-role/:role_name

6. Динамические роли

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

6.1. Создание/удаление конфигурации динамической роли

Создает, обновляет или удаляет динамическую роль.

Метод Путь

POST

/ldap/role/:role_name

DELETE

/ldap/role/:role_name

Конечная точка POST позволяет частично обновлять существующие роли. Если роль существует и будет выполнен запрос POST, то будут обновлены только указанные в запросе ключи. Чтобы удалить значение, укажите ключ с пустой строкой в качестве значения. Пример: starvault write ldap/role/myrole default_ttl=""

6.1.1. Параметры

  • role_name (string, обязательный) - имя динамической роли.

  • creation_ldif (string, обязательный) - шаблонная строка LDIF, используемая для создания учетной записи пользователя. Эта строка может содержать несколько записей LDIF. creation_ldif также может использоваться для добавления учетной записи пользователя в существующую группу. Все записи LDIF выполняются в определённом порядке. Если StarVault сталкивается с ошибкой во время выполнения creation_ldif, он остановится при первой ошибке и не выполнит никакие оставшиеся записи LDIF. Если произошла ошибка и указан rollback_ldif, записи LDIF в rollback_ldif будут выполнены. См. rollback_ldif для получения дополнительных деталей. Это поле может быть опционально предоставлено в виде строки, закодированной в base64.

  • deletion_ldif (string, обязательный) - шаблонная строка LDIF, используемая для удаления учетной записи пользователя после истечения его TTL. Эта строка может содержать несколько записей LDIF. Все записи LDIF выполняются в порядке. Если StarVault сталкивается с ошибкой при выполнении записи в deletion_ldif, он попытается продолжить выполнение оставшихся записей. Это поле может быть опционально предоставлено в виде строки, закодированной в base64.

  • rollback_ldif (string, не обязательно, но рекомендуется) - шаблонная строка LDIF, используемая для попытки отката любых изменений в случае, если выполнение creation_ldif приводит к ошибке. Эта строка может содержать несколько записей LDIF. Все записи LDIF выполняются в порядке. Если StarVault сталкивается с ошибкой при выполнении записи в rollback_ldif, он попытается продолжить выполнение оставшихся записей. Это поле может быть опционально предоставлено в виде строки, закодированной в base64.

  • username_template (string) - шаблон, используемый для генерации динамического имени пользователя. Это будет использоваться для заполнения поля .Username внутри строки creation_ldif.

Шаблон имени по умолчанию:
v_{{.DisplayName}}_{{.RoleName}}_{{random 10}}_{{unix_time}}

Примеры имен пользователей:

Пример

DisplayName

token

RoleName

myrolename

Имя пользователя

v_token_myrolename_uszt1n4cyh_1614294836
Пример

DisplayName

amuchlonger_dispname

RoleName

role-name-with-dashes

Имя пользователя

v_amuchlonger_dispname_role-name-with-dashes_s0t9xb0jsa_1614294836

  • default_ttl (string/int) - указывает TTL для аренды, связанной с этой ролью. Принимает строки формата продолжительности. По умолчанию используется системное/движковое время по умолчанию TTL.

  • max_ttl (string/int) - указывает максимальный TTL для аренды, связанной с этой ролью. Принимает строки формата продолжительности. По умолчанию используется системное/монтируемое время по умолчанию TTL; это значение может быть меньше максимального значения TTL монтирования (или, если не установлено, максимального значения системного TTL), но не может быть больше.

Поля creation_ldif, deletion_ldif, rollback_ldif и username_template все являются шаблонами. См. Шаблонизация имен пользователей для получения деталей о том, как использовать шаблонизацию.

6.1.2. Пример тела запроса

Далее представлены примеры файлов LDIF:

creation.ldif:
dn: cn={{.Username}},ou=users,dc=learn,dc=example
objectClass: person
objectClass: top
cn: learn
sn: {{.Password | utf16le | base64}}
memberOf: cn=dev,ou=groups,dc=learn,dc=example
userPassword: {{.Password}}
deletion.ldif & rollback.ldif:
dn: cn={{.Username}},ou=users,dc=learn,dc=example
changetype: delete
Полная полезная нагрузка:
{
  "creation_ldif": "...",
  "deletion_ldif": "...",
  "rollback_ldif": "...",
  "username_template": "...",
  "default_ttl": "1h",
  "max_ttl": "24h"
}

Заявления LDIF могут быть закодированы в base64. Если они закодированы в base64 при создании/обновлении конфигурации роли, декодированная версия будет возвращена с конечной точкой GET.
Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/role/dynamic-role

6.2. Чтение конфигурации динамической роли

Извлекает конфигурацию динамической роли.

Метод Путь

GET

/ldap/role/:role_name
Ответ:
200 OK
{
  "creation_ldif": "...",
  "default_ttl": 1800,
  "deletion_ldif": "...",
  "max_ttl": 0,
  "rollback_ldif": "...",
  "username_template": "..."
}

6.3. Шаблоны

Шаблоны LDIF и имени пользователя используют синтаксис шаблонов Go для создания LDIF/имени пользователя, которое будет выполнено на сервере. Это делается потому, что некоторые значения (такие как имя пользователя и пароль в заявлении LDIF) неизвестны на уровне конфигурации. Кроме того, шаблон дает большой гибкость оператору для построения LDIF и имени пользователя.

Шаблонные поля ограничены {{ и }}. Для ссылки на поле (например, сгенерированное Username) перед именем поля ставится точка. Пример: {{.Username}}. Пробелы могут быть включены между {{ и }}. Например: {{.Username|lowercase}} - это то же самое, что и {{ .Username | lowercase }}.

Если поле нужно изменить (например, хэш SHA256, кодирование base64 и т.д.), значение можно передать одной из встроенных функций. Это использует синтаксис "трубопровод": {{.Username | base64}}. Значения могут быть "пропущены" через несколько функций: {{.Username | lowercase | base64}}.

6.3.1. Поля шаблона LDIF

Следующие параметры доступны в шаблонах LDIF:

  • .Username - имя сгенерированного пользователя (опционально из username_template).

    Шаблон по умолчанию: v_<display name>_<role name>_<10 random chars>_<unix timestamp>

  • .Password - сгенерированный пароль (опционально из политик паролей)

  • .RoleName - Имя роли, для которой генерируются учетные данные.

  • .DisplayName - Отображаемое имя, связанное с токеном аутентификации, используемым для запроса учетных данных.

  • .IssueTime - Время, когда аренда была создана. Это время может быть немного ранее, чем связанная аренда из-за того, где это значение рассчитывается по сравнению с тем, где StarVault рассчитывает детали аренды.

    Формат: 2006-01-02T15:04:05Z07:00 (RFC3339)

  • .IssueTimeSeconds - Универсальное время, когда аренда была создана. Это время может быть немного ранее, чем связанная аренда из-за где это значение рассчитывается по сравнению с тем, где StarVault рассчитывает детали аренды.

    Формат: Целое число, указывающее, сколько секунд прошло с 1 января 1970 года.

  • .ExpirationTime - Время, когда аренда должна истечь. Это время может быть немного ранее, чем связанная аренда из-за где это значение рассчитывается по сравнению с тем, где StarVault рассчитывает детали аренды.

    Формат: 2006-01-02T15:04:05Z07:00 (RFC3339)

  • .ExpirationTimeSeconds - Универсальное время, когда аренда должна истечь. Это время может быть немного ранее, чем связанная аренда из-за где это значение рассчитывается по сравнению с тем, где StarVault рассчитывает детали аренды.

    Формат: Целое число, указывающее, сколько секунд прошло с 1 января 1970 года.

6.3.2. Поля шаблона имени пользователя

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

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

Если RoleName - это test-role, а username_template - это v_{{.RoleName}}_{{unix_time}}, результатом этого шаблона может быть: v_test-role_1234567890. Обратите внимание на символ - (дефис) в test-role. Если LDAP система, которую управляет StarVault, ограничивает имена пользователей/DN так, чтобы дефисы (или другие символы) не разрешались, шаблон должен явно модифицировать/удалить эти символы. В этом примере шаблон можно изменить на v_{{.RoleName | replace "-" "_"}}, чтобы заменить дефисы на подчеркивания.

  • .RoleName - Имя роли, из которой генерируются учетные данные.

  • .DisplayName - Отображаемое имя, связанное с пользователем, который делает запрос против Значения.

6.3.3. Функции шаблона

И шаблоны LDIF, и шаблон имени пользователя используют язык шаблонов Go, поэтому поддерживаются все функции и возможности этого языка, включая функции, такие как printf.

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

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

    Пример: {{random 20}} генерирует 20 случайных символов.

  • truncate - обрезает предыдущее значение до указанного количества символов.

    Пример: {{.FieldName | truncate 10}}

  • truncate_sha256 - обрезает предыдущее значение до указанного количества символов. Последние 8 символов обрезанного значения будут первыми 8 символами хеша SHA256 обрезанных символов.

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

    Пример: v_{{.RoleName | truncate_sha256 15}}_{{unix_time}}.

    Если существуют две роли для этого шаблона, myreallylongprefix-foobar и myreallylongprefix-bazqux, имя пользователя для первой роли будет v_myrealle6da86ec_1234567890, а для второй роли оно будет v_myrealld0420a55_1234567890.

  • uppercase - приводит к верхнему регистру указанное значение.

    Пример: {{.FieldName | uppercase}}

  • lowercase - приводит к нижнему регистру указанное значение.

    Пример: {{.FieldName | lowercase}}

  • replace - найдите/замените указанное значение.

    Пример: {{.FieldName | replace "-" "_"}}

  • sha256 - вычисляет SHA256 хеш указанного значения.

    Пример: {{.FieldName | sha256}}

  • base64 - кодирует указанное значение в base64.

    Пример: {{.FieldName | base64}}

  • unix_time - Текущая временная метка UNIX (количество секунд с 1 января 1970 года).

    Пример: {{unix_time}}

  • unix_time_millis - текущая временная метка UNIX в миллисекундах.

    Пример: {{unix_time_millis}}

  • timestamp - текущее время. Необходимо предоставить строку форматирования на основе пакета time языка Go.

    Пример: {{timestamp "2006-01-02T15:04:05Z"}}

  • uuid - генерирует случайный UUID.

    Пример: {{uuid}}

6.3.3.1. Функции шаблона LDIF

Кроме того, шаблоны LDIF включают дополнительную функцию для упрощения обработки паролей Active Directory. Шаблон имени пользователя не может использовать эту функцию.

  • utf16le - Кодирует указанное значение в UTF16-LE.

    Пример: {{.FieldName | utf16le}}

7. Пароли динамической роли

Конечная точка creds предлагает информацию о учетных данных для данной динамической роли.

Метод Путь

GET

/ldap/creds/:role_name
Пример get запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    http://127.0.0.1:8200/v1/ldap/creds/dynamic-role
Пример get ответа:
{
  "distinguished_names": [
    "cn=v_token-dispname_testrole_jmZMnjS42a_1680580467,ou=users,dc=starvault,dc=com"
  ],
  "password": "OWexB3OzYYLFiotWxUS2EheGpriwR20fa2yA7JGTsnBREcxyqpwf73htofMihxcC",
  "username": "v_token-dispname_testrole_jmZMnjS42a_1680580467"
}

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

Конечная точка library настраивает наборы сервисных учетных записей, которые StarVault будет предлагать для выдачи.

Метод Путь

LIST

/ldap/library

POST

/ldap/library/:set_name

GET

/ldap/library/:set_name

DELETE

/ldap/library/:set_name

При добавлении учетной записи сервиса в библиотеку StarVault проверяет, существует ли она уже в LDAP каталоге.

8.1. Параметры

  • name (string: "", обязательный) - имя набора сервисных учетных записей.

  • service_account_names (string: "", или список: [] обязательный) - имена всех сервисных учетных записей, которые могут быть выданы из этого набора. Эти сервисные учетные записи должны использоваться только StarVault и могут находиться только в одном наборе. Эти сервисные учетные записи должны уже существовать в LDAP каталоге.

  • ttl (duration: "24h", опционально) - максимальная длительность аренды для единичной выдачи, прежде чем StarVault автоматически её вернет. По умолчанию - 24 часа. Установка нуля отражает неограниченный срок займа. Использует строки формата продолжительности.

  • max_ttl (duration: "24h", опционально) - максимальная длительность аренды, длительности работы с продлением, прежде чем StarVault автоматически её вернет. По умолчанию - 24 часа. Установка нуля отражает неограниченный срок займа. Использует строки формата продолжительности.

  • disable_check_in_enforcement (bool: false, опционально) - отключить требование, чтобы сервисные учетные записи должны быть возвращены самой сущностью или клиентским токеном, который их выдал. По умолчанию - false.

Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/library/accounting-team
Пример POST полезной нагрузки:
{
  "service_account_names": ["fizz@example.com", "buzz@example.com"],
  "ttl": "10h",
  "max_ttl": "20h",
  "disable_check_in_enforcement": false
}
Пример GET ответа:
{
  "service_account_names": ["fizz@example.com", "buzz@example.com"],
  "ttl": "10h",
  "max_ttl": "20h",
  "disable_check_in_enforcement": false
}

8.2. Пример LIST ответа

Выполнение LIST по конечной точке /ldap/library отобразит имена всех наборов сервисных учетных записей, содержащихся в StarVault.

["accounting-team"]

9. Проверка статуса набора библиотек

Этот конечный пункт предоставляет статус выдачи учетных записей сервисов в наборе библиотек.

Метод Путь

GET

/ldap/library/:set_name/status
Пример GET запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    http://127.0.0.1:8200/v1/ldap/library/accounting-team/status
Пример GET ответа:
{
  "request_id": "9e44c8b5-d142-5867-2a11-49f3ba71215a",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "buzz@example.com": {
      "available": true
    },
    "fizz@example.com": {
      "available": false,
      "borrower_client_token": "4c653e473bf7e27c6759fccc3def20c44d776279",
      "borrower_entity_id": "631256b1-8523-9838-5501-d0a1e2cdad9c"
    }
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

10. Управление выдачей

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

Метод Путь

POST

/ldap/library/:set_name/check-out

Возвращает 200, если учетные данные доступны, и 400, если никаких учетных данных не доступно.

10.1. Параметры

  • name (string: "", обязательный) - имя набора сервисных учетных записей.

  • ttl (duration: "", опционально) - максимальная длительность аренды, прежде чем StarVault автоматически её вернет. Установка нуля отражает неограниченный срок займа. По умолчанию используется ttl набора. Если запрашиваемый ttl больше, чем в наборе, то используется ttl из набора. Использует строки формата продолжительности.

Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/library/accounting-team/check-out
Пример POST полезной нагрузки:
{
  "ttl": "1h"
}
Пример POST ответа:
{
  "request_id": "364a17d4-e5ab-998b-ceee-b49929229e0c",
  "lease_id": "ad/library/accounting-team/check-out/aoBsaBEI4PK96VnukubvYDlZ",
  "renewable": true,
  "lease_duration": 36000,
  "data": {
    "password": "?@09QW0KZ8DSBu3deIu7XLY1NZqzwhozmMAZ6v0IcZJGOjs5GvpVMvOeW7/duls2",
    "service_account_name": "fizz@example.com"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

11. Управление возвратом

По умолчанию возврат должен быть выполнен той же сущностью или клиентским токеном, который использовался для выдачи. Чтобы отключить это поведение, используйте переключатель disable_check_in_enforcement на наборе библиотек. Или используйте путь ad/library/manage/:set_name/check-in, чтобы принудительно вернуть учетную запись. Доступ к конечной точке "управление" должен быть предоставлён только высокоправомочным пользователям StarVault, таким как операторы StarVault.

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

Метод Путь

POST

/ldap/library/:set_name/check-in

POST

/ldap/library/manage/:set_name/check-in

11.1. Параметры

  • name (string: "", обязательный) - имя набора сервисных учетных записей.

  • service_account_names (string: "", или список: [] опционально) - имена всех сервисных учетных записей, которые нужно вернуть. Может быть опущено, если возвращается только одна учетная запись.

Пример POST запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/ldap/library/accounting-team/check-in
Пример POST полезной нагрузки:
{
  "service_account_names": ["fizz@example.com"]
}
Пример POST ответа:
{
  "request_id": "db45c714-3f68-b748-95bc-8f7467637a52",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "check_ins": ["fizz@example.com"]
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}