Аутентификация пользователей с помощью PKI

Добавьте конфигурацию сферы для сферы pki в elasticsearch.yml в пространстве имен xpack.security.authc.realms.pki. Вы должны явно установить атрибут order. См. настройки сферы PKI для всех параметров, которые вы можете установить для сферы pki.

Например, следующий фрагмент показывает самую базовую конфигурацию сферы pki:

xpack:
  security:
    authc:
      realms:
        pki:
          pki1:
            order: 1

С этой конфигурацией любой сертификат, которому доверяет уровень SSL/TLS Elasticsearch, принимается для аутентификации. Имя пользователя — это общее имя (CN), извлеченное из DN в поле Subject сертификата конечного узла. Эта конфигурация недостаточна для разрешения аутентификации PKI в Kibana; необходимы дополнительные шаги.

Необязательно: имя пользователя определяется с помощью username_pattern. Если вы хотите использовать что-то другое, помимо CN Subject DN, как имя пользователя, вы можете указать регулярное выражение для извлечения нужного имени пользователя. Регулярное выражение применяется к Subject DN.

Например, регулярное выражение в следующей конфигурации извлекает адрес электронной почты из Subject DN:

xpack:
  security:
    authc:
      realms:
        pki:
          pki1:
            order: 1
            username_pattern: "EMAILADDRESS=(.*?)(?:,|$)"

Включите аутентификацию клиентов на нужных сетевых уровнях (транспорт или http).

При подключении клиентов напрямую к Elasticsearch и отсутствии прокси-аутентификации, сфера PKI опирается на настройки TLS сетевого интерфейса узла. Сфера может быть настроена более строго, чем основное сетевое подключение. То есть, можно настроить узел таким образом, что некоторые подключения принимаются сетевым интерфейсом, но затем не проходят аутентификацию в сфере PKI. Однако обратное невозможно. Сфера PKI не может пройти аутентификацию подключения, которое было отклонено сетевым интерфейсом.

В частности, это означает:

Для объяснения этих настроек см. Общие настройки TLS.

Соответствующий сетевой интерфейс (транспорт или http) должен быть настроен на доверие любому сертификату, который будет использоваться в рамках сферы PKI. Однако можно настроить сферу PKI так, чтобы она доверяла только подмножеству сертификатов, принятых сетевым интерфейсом. Это полезно, когда уровень SSL/TLS доверяет клиентам с сертификатами, подписанными другим центром сертификации, отличным от того, который подписывает сертификаты ваших пользователей.

Для настройки сферы PKI со своим хранилищем доверенных сертификатов укажите параметр truststore.path. Путь должен находиться в каталоге конфигурации Elasticsearch (ES_PATH_CONF). Например:

xpack:
  security:
    authc:
      realms:
        pki:
          pki1:
            order: 1
            truststore:
              path: "pki1_truststore.jks"

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

bin/elasticsearch-keystore add \
xpack.security.authc.realms.pki.pki1.truststore.secure_password

Параметр certificate_authorities может использоваться как альтернатива настройке truststore.path, когда файлы сертификатов имеют формат PEM. Настройка принимает список. Два параметра взаимоисключают друг друга, они не могут использоваться одновременно.

Настройка ролей для пользователей PKI.

Вы настраиваете роли для пользователей PKI с помощью API сопоставлений ролей или с помощью файла, хранящегося на каждом узле. Обе конфигурации объединяются. Когда пользователь проходит аутентификацию в сфере PKI, привилегии для этого пользователя являются объединением всех привилегий, определенных ролями, которым сопоставлен пользователь.

Пользователь идентифицируется по уникальному имени (DN) в его сертификате. Например, следующая конфигурация сопоставления назначает John Doe роль user с помощью API сопоставления ролей:

resp = client.security.put_role_mapping(
    name="users",
    roles=[
        "user"
    ],
    rules={
        "field": {
            "dn": "cn=John Doe,ou=example,o=com"
        }
    },
    enabled=True,
)
print(resp)

const response = await client.security.putRoleMapping({
  name: "users",
  roles: ["user"],
  rules: {
    field: {
      dn: "cn=John Doe,ou=example,o=com",
    },
  },
  enabled: true,
});
console.log(response);

PUT /_security/role_mapping/users
{
  "roles" : [ "user" ],
  "rules" : { "field" : {
    "dn" : "cn=John Doe,ou=example,o=com" 
  } },
  "enabled": true
}

В качестве альтернативы используйте файл сопоставления ролей. Например:

user: 
  - "cn=John Doe,ou=example,o=com" 

Путь к файлу по умолчанию — ES_PATH_CONF/role_mapping.yml. Вы можете указать другой путь (который должен находиться в ES_PATH_CONF) с помощью настройки сферы files.role_mapping (например, xpack.security.authc.realms.pki.pki1.files.role_mapping).

Уникальное имя (DN) пользователя PKI соответствует соглашениям X.500 об именовании, которые помещают наиболее специфические поля (например, cn или uid) в начале имени и наиболее общие поля (например, o или dc) — в конце. Некоторые инструменты, такие как openssl, могут выводить имя субъекта в другом формате.

Один из способов определения правильного DN для сертификата — использование API authenticate API (использование соответствующего сертификата PKI в качестве средства аутентификации) и проверка поля metadata в результате. Уникальное имя пользователя будет добавлено под ключом pki_dn. Вы также можете использовать API аутентификации для проверки вашего сопоставления ролей.

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