Механизм секретов LDAP

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

Механизм секретов LDAP предоставляет возможность управлять LDAP-учетными данными, а также динамически создавать учетные записи. Поддерживаются реализации протокола LDAP v3, включая OpenLDAP, Active Directory и IBM RACF (Resource Access Control Facility).

Основные возможности:

Статические учетные данные
Динамические учетные данные
Проверка/аренда сервисных аккаунтов (Service Account Check-Out)

1. Настройка

Включите механизм секретов LDAP:
```
$ starvault secrets enable ldap
```
По умолчанию, механизм монтируется под именем ldap. Чтобы использовать другой путь, добавьте аргумент -path.
Настройте учетные данные, которые StarVault использует для связи с LDAP для генерации паролей:
```
$ starvault write ldap/config \
    binddn=$USERNAME \
    bindpass=$PASSWORD \
    url=ldaps://138.91.247.105
```
Рекомендуется создать отдельную учетную запись управления входом специально для StarVault.

Смените пароль root, чтобы только StarVault знал учетные данные:

$ starvault write -f ldap/rotate-root

Получить сгенерированный пароль после смены в StarVault невозможно. Рекомендуется создать отдельную учетную запись управления входом специально для StarVault.

2. Схемы

Механизм секретов LDAP поддерживает три различные схемы:

openldap (default)
racf
ad

2.1. OpenLDAP

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

organization
organizationalUnit
organizationalRole
inetOrgPerson
person
posixAccount

2.2. Средство контроля доступа к ресурсам (RACF)

Для управления системой безопасности IBM Resource Access Control Facility (RACF) механизм секретов должен быть настроен на использование схемы racf.

Для поддержки RACF генерируемые пароли должны состоять из 8 символов или меньше. Длина пароля может быть настроена с помощью политики паролей:

$ starvault write ldap/config \
    binddn=$USERNAME \
    bindpass=$PASSWORD \
    url=ldaps://138.91.247.105 \
    schema=racf \
    password_policy=racf_password_policy

3. Active Directory (AD)

Для управления экземплярами Active Directory механизм секретов должен быть настроен на использование схемы ad.

$ starvault write ldap/config \
    binddn=$USERNAME \
    bindpass=$PASSWORD \
    url=ldaps://138.91.247.105 \
    schema=ad

4. Статические учетные данные

4.1. Настройка

Настройте статическую роль, которая сопоставляет имя в StarVault с записью в LDAP. Настройки ротации паролей будут управляться этой ролью.
```
$ starvault write ldap/static-role/domain \
    dn='uid=domain,ou=users,dc=domain,dc=com' \
    username='domain' \
    rotation_period="24h"
```
Запрос учетных данных для роли "domain":
```
$ starvault read ldap/static-cred/domain
```

4.2. Смена пароля

Управление паролями может осуществляться двумя способами:

автоматическая смена по времени;
ручное изменение.

4.3. Автоматическое изменение пароля

Пароли будут автоматически изменяться в соответствии с периодом ротации (rotation_period), настроенным в статической роли (минимум 5 секунд). При запросе учетных данных для статической роли в ответе будет указано время до следующей ротации (ttl).

В настоящее время автоизменение поддерживается только для статических ролей. Учетная запись binddn, используемая StarVault, должна быть изменена с помощью конечной точки rotate-root, чтобы сгенерировать пароль, который будет известен только StarVault.

4.4. Изменение вручную

Статические роли могут быть вручную изменены с помощью конечной точки rotate-role. При ручном изменении период изменения начинается заново.

4.5. Удаление статических ролей

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

5. Динамические учетные записи

5.1. Настройка

Динамические учетные данные можно настроить, вызвав конечную точку /role/:role_name:

$ starvault write ldap/role/dynamic-role \
  creation_ldif=@/path/to/creation.ldif \
  deletion_ldif=@/path/to/deletion.ldif \
  rollback_ldif=@/path/to/rollback.ldif \
  default_ttl=1h \
  max_ttl=24h

Аргумент rollback_ldif необязателен, но рекомендуется. Операторы, содержащиеся в rollback_ldif, будут выполнены, если создание по какой-либо причине завершится неудачей. Это гарантирует, что все сущности будут удалены в случае неудачи.

Для создания учетной записи выполните команду:

$ starvault read ldap/creds/dynamic-role

**Вывод:**
Key	Value
---	----
lease_id	ldap/creds/dynamic-role/HFgd6uKaDomVMvJpYbn9q4q5
lease_duration	1h
lease_renewable	true
distinguished_names	[cn=v_token_dynamic-role_FfH2i1c4dO_1611952635,ou=users,dc=learn,dc=example]
password	xWMjkIFMerYttEbzfnBVZvhRQGmhpAA0yeTya8fdmDB3LXDzGrjNEPV2bCPE9CW6
username	v_token_testrole_FfH2i1c4dO_1611952635

Поле distinguished_names представляет собой массив DN, которые создаются из операторов create_ldif. Если включено более одной записи LDIF, в это поле будут включены DN из каждого утверждения. Каждая запись в этом поле соответствует одному LDIF-выражению. Дедупликации не происходит, и порядок сохраняется.

5.2. Сущности LDIF

Управление учетными записями пользователей осуществляется с помощью записей LDIF. Записи LDIF могут представлять собой base64-кодированную версию строки LDIF. Строка будет разобрана и проверена на соответствие синтаксису LDIF. Хороший справочник по правильному синтаксису LDIF можно найти здесь.

Некоторые важные моменты, которые следует помнить при создании записей LDIF:

Ни в одной строке не должно быть пробелов, включая пустые строки;
Каждый блок модификации должен предваряться пустой строкой;
В одном блоке модификации можно задать несколько модификаций для dn. Каждая модификация должна завершаться одним тире (-)

5.3. Active Directory (AD)

Для AD есть несколько дополнительных деталей, которые важно помнить:

Чтобы программно создать пользователя в AD, вы сначала добавляете объект пользователя, а затем изменяете его, чтобы указать пароль и включить учетную запись.

Пароли в AD задаются с помощью поля unicodePwd. Перед ним должны стоять два (2) двоеточия (::).
При программной установке пароля в AD должны быть соблюдены следующие критерии:
- Пароль должен быть заключен в двойные кавычки (" ");
- Пароль должен быть в формате UTF16LE;
- Пароль должен быть в base64-кодировке;
- Дополнительные сведения можно найти здесь.
После того как пароль пользователя установлен, его можно включить. Для этого в AD используется поле userAccountControl:
- Чтобы включить учетную запись, установите значение userAccountControl равным 512;
- Скорее всего, вы также захотите отключить истечение срока действия пароля AD для этой динамической учетной записи пользователя. Значение userAccountControl для этого следующее: 65536;
- Флаги userAccountControl являются кумулятивными, поэтому, чтобы установить оба вышеуказанных флага, сложите два значения (512 + 65536 = 66048): переведите userAccountControl в 66048;
- Подробнее о флагах userAccountControl см. здесь.

sAMAccountName - это общее поле при работе с пользователями AD. Оно используется для обеспечения совместимости с устаревшими системами Windows NT и имеет ограничение в 20 символов. Помните об этом при определении шаблона username_template. Дополнительные сведения см. здесь.

Поскольку шаблон username_template по умолчанию длиннее 20 символов и соответствует шаблону v_{{.DisplayName}}_{{.RoleName}}_{{random 10}}_{{unix_time}}, мы рекомендуем настроить шаблон username_template в конфигурации роли, чтобы генерировать учетные записи с именами менее 20 символов. Для получения дополнительной информации обратитесь к документу о шаблонах имен пользователей.

Что касается добавления динамических пользователей в группы, AD не позволяет напрямую изменять атрибут memberOf пользователя. Атрибут member группы и атрибут memberOf пользователя являются связанными атрибутами. Связанные атрибуты представляют собой пары прямая ссылка/обратная ссылка, причем прямая ссылка может быть изменена. В случае членства в группе AD атрибут member группы является прямой ссылкой. Чтобы добавить вновь созданного динамического пользователя в группу, нам также нужно отправить запрос modify в нужную группу и обновить членство в группе для нового пользователя.

5.3.1. Пример LDIF для Active Directory

Различные параметры *_ldif представляют собой шаблоны, использующие язык шаблонов go. Полный пример LDIF для создания учетной записи пользователя Active Directory приведен здесь для справки:

dn: CN={{.Username}},OU=domain,DC=adtesting,DC=lab
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
userPrincipalName: {{.Username}}@adtesting.lab
sAMAccountName: {{.Username}}

dn: CN={{.Username}},OU=domain,DC=adtesting,DC=lab
changetype: modify
replace: unicodePwd
unicodePwd::{{ printf "%q" .Password | utf16le | base64 }}
-
replace: userAccountControl
userAccountControl: 66048
-

dn: CN=test-group,OU=domain,DC=adtesting,DC=lab
changetype: modify
add: member
member: CN={{.Username}},OU=domain,DC=adtesting,DC=lab
-

6. Проверка учетной записи сервиса

Проверка учетной записи сервиса предоставляет библиотеку учетных записей сервиса, которые могут быть проверены человеком или машиной. StarVault автоматически меняет пароль при каждой регистрации учетной записи. Учетные записи сервисов можно регистрировать добровольно, или StarVault будет регистрировать их, когда закончится период кредитования ("ttl").

Функциональность проверки учетных записей сервисов работает с различными схемами, включая OpenLDAP, Active Directory и RACF. В следующем примере использования механизм секретов настроен на управление библиотекой учетных записей сервисов в экземпляре Active Directory.

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

$ starvault secrets enable ldap
Success! Enabled the ad secrets engine at: ldap/

$ starvault write ldap/config \
    binddn=$USERNAME \
    bindpass=$PASSWORD \
    url=ldaps://138.91.247.105 \
    userdn='dc=example,dc=com'

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

$ starvault write ldap/library/accounting-team \
    service_account_names=fizz@example.com,buzz@example.com \
    ttl=10h \
    max_ttl=20h \
    disable_check_in_enforcement=false

В этом примере имена учетных записей сервисов fizz@example.com и buzz@example.com уже созданы на удаленном сервере AD. Они были выделены исключительно для работы StarVault.

ttl - это время, в течение которого каждая проверка будет длиться до того, как StarVault проверит учетную запись сервиса, сменив ее пароль во время регистрации.

max_ttl - максимальное количество времени, которое она может прожить, если ее обновить.

По умолчанию они равны 24 часам, и в обоих случаях используются строки формата duration. Также по умолчанию учетная запись сервиса должна регистрироваться той же сущностью StarVault или клиентским токеном, которая ее зарегистрировала. Однако если такое поведение вызывает проблемы, установите disable_check_in_enforcement=true.

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

$ starvault read ldap/library/accounting-team/status

**Вывод:**
Key	Value
---	----
buzz@example.com	map[available:true]
fizz@example.com	map[available:true]

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

$ starvault write -f ldap/library/accounting-team/check-out

**Вывод:**
Key	Value
---	----
lease_id	ldap/library/accounting-team/check-out/EpuS8cX7uEsDzOwW9kkKOyGW
lease_duration	10h
lease_renewable	true
password	?@09AZKh03hBORZPJcTDgLfntlHqxLy29tcQjPVThzuwWAx/Twx4a2ZcRQRqrZ1w
service_account_name	fizz@example.com

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

$ starvault write ldap/library/accounting-team/check-out ttl=30m

**Вывод:**
Key	Value
---	----
lease_id	ldap/library/accounting-team/check-out/gMonJ2jB6kYs6d3Vw37WFDCY
lease_duration	30m
lease_renewable	true
password	?@09AZerLLuJfEMbRqP+3yfQYDSq6laP48TCJRBJaJu/kDKLsq9WxL9szVAvL/E1
service_account_name	buzz@example.com

Это может быть хорошим способом сказать: "Хотя я могу выписать учетную запись на 24 часа, если я не зарегистрировал ее через 30 минут, значит, я забыл или я экземпляр с истекшим сроком использования, поэтому вы можете просто зарегистрировать учетную запись обратно".

Если ни одна учетная запись службы не доступна для выгрузки, StarVault вернет 400 Bad Request.

$ starvault write -f ldap/library/accounting-team/check-out
Error writing data to ldap/library/accounting-team/check-out: Error making API request.

URL: POST http://localhost:8200/v1/ldap/library/accounting-team/check-out
Code: 400. Errors:

* No service accounts available for check-out.

Чтобы продлить работу учетной записи, возобновите ее аренду.

$ starvault lease renew ldap/library/accounting-team/check-out/0C2wmeaDmsToVFc0zDiX9cMq

**Вывод:**
Key	Value
---	----
lease_id	ldap/library/accounting-team/check-out/0C2wmeaDmsToVFc0zDiX9cMq
lease_duration	10h
lease_renewable	true

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

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

$ starvault write -f ldap/library/accounting-team/check-in

**Вывод:**
Key	Value
---	----
check_ins	[fizz@example.com]

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

$ starvault write ldap/library/accounting-team/check-in service_account_names=fizz@example.com

**Вывод:**
Key	Value
---	----
check_ins	[fizz@example.com]

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

Если пользователь не может проверить учетную запись сервиса или просто не пытается это сделать, StarVault автоматически проверит ее по истечении ttl. Однако если это слишком долго, учетные записи сервисов могут быть принудительно зарегистрированы высокопривилегированным пользователем:

$ starvault write -f ldap/library/manage/accounting-team/check-in

**Вывод:**
Key	Value
---	----
check_ins	[fizz@example.com]

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

$ starvault lease revoke ldap/library/accounting-team/check-out/PvBVG0m7pEg2940Cb3Jw3KpJ
All revocation operations queued successfully!

7. Генерация паролей

Ранее этот механизм позволял настраивать длину пароля, который генерируется при ротации учетных данных. Этот способ был признан устаревшим начиная с Vault 1.5 в пользу использования политик паролей. Это означает, что поле length больше не следует использовать. Следующая политика паролей может быть использована для воспроизведения аналогичного поведения, которое обеспечивалось через поле length:

length=<length>
rule "charset" {
  charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
}

8. Политика паролей LDAP

Механизм секретов LDAP не хэширует и не шифрует пароли перед тем, как изменить значения в LDAP. Такое поведение может привести к тому, что пароли будут храниться в открытом виде.

Чтобы избежать хранения паролей в открытом виде, сервер LDAP должен быть настроен с использованием политики паролей LDAP (ppolicy — не путать с политикой паролей StarVault). Политика ppolicy позволяет, например, автоматически хэшировать открытые пароли.

Ниже приведён пример политики паролей LDAP, обеспечивающей хэширование паролей в дереве данных (DIT) dc=domain,dc=com:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy

dn: olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcPPolicyConfig
objectClass: olcOverlayConfig
olcOverlay: {2}ppolicy
olcPPolicyDefault: cn=default,ou=pwpolicies,dc=domain,dc=com
olcPPolicyForwardUpdates: FALSE
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE

9. API

Механизм секретов LDAP предоставляет полноценный HTTP API. Подробнее см. в документации по API LDAP Secrets Engine.