Проверка подлинности пользователей с использованием 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; требуются дополнительные шаги.

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

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

xpack:
  security:
    authc:
      realms:
        pki:
          pki1:
            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:
            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, права для этого пользователя представляют собой объединение всех прав, определенных ролями, которым сопоставлен пользователь.

Пользователь определяется по имени distinguished name в их сертификате. Например, следующая конфигурация сопоставления отображает John Doe на роль user с помощью API сопоставления ролей:

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).

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

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

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