Set up Enterprise Search with PKI user authentication

edit

Set up Enterprise Search with PKI user authentication

edit

PKI authentification for Enterprise Search is a gold feature. In addition, PKI is only supported in Enterprise Search in Kibana.

The following documentation describes the process of configuring Elasticsearch and Kibana:

PKI user authentication

If you are using the standalone Enterprise Search UI, make sure that the realms configured in Enterprise Search mirror those configured in Elasticsearch. For example, if Elasticsearch has both native and pki enabled:

xpack.security.authc.realms:
  native:
    native1:
      order: 0
  pki:
    pki1:
      order: 1
      delegation.enabled: true
      truststore.path: certs/my-organization-certificates.p12

Then Enterprise Search should have those as well:

ent_search.auth:
  native1:
    source: elasticsearch-native
    order: 1
  pki1:
    source: elasticsearch-pki
    order: 2

If you are using the Kibana UI, within your Enterprise Search configuration settings, make sure that:

kibana.host is set
kibana.external_url is set
any auth.source configurations are removed.

Instructions specific to Elastic Cloud users

edit

On Elastic Cloud:

it’s not possible to remove ent_search.auth section
kibana.external_url is applied automatically and is not part of user settings
elasticsearch-native auth source is always added automatically to the list of sources, and should not be included in user settings.

Elastic Cloud users should explicitly configure auth sources in the Enterprise Search config, whether they intend to use Kibana or Enterprise Search UI to log in.

Example:

ent_search.auth:
  pki1:
    source: elasticsearch-pki
    order: 1

Configure Enterprise Search role mappings for PKI users

edit

When you configured Elasticsearch and Kibana for PKI authentication using the documentation links above, one of the steps advised you to create a role mapping to be able to access Kibana. As a very simple and permissive example, you can give all users in pki1 realm superuser role, and that will also give them full access to App Search and Workplace Search:

PUT /_security/role_mapping/pki1_mapping
{
  "roles": [ "superuser" ],
  "enabled": true,
  "rules": {
    "all": [
      {"field": { "realm.name": "pki1"}}}
    ]
  }
}

However, it’s better to have more control. In the following example, users who successfully log in to the pki1 realm get full access to Kibana, but no access to Enterprise Search:

PUT /_security/role_mapping/pki1_mapping
{
  "roles": [ "kibana_admin" ],
  "enabled": true,
  "rules": {
    "all": [
      {"field": { "realm.name": "pki1"}}}
    ]
  }
}

In this case, pki1 users can be managed via Enterprise Search mappings. Before any mappings can be created, it is necessary to enable role-based access (RBAC) mode in either App Search or Workplace Search. After that, users can be mapped in Users and Roles.

Mapping can use common Elasticsearch user attributes, such as username and email, but also anything provided in metadata that is returned by the provider. A user logged in with a PKI certificate would have a pki_dn (distinguished name) populated in metadata. Example:

{
    "pki_dn": "CN=john.smith, OU=Example Company Users, DC=example, DC=com",
    "pki_delegated_by_realm": "pki1",
    "pki_delegated_by_user": "localhost"
}

We could give users different permissions applying a pattern match on the pki_dn. In the following snippet, Example Company Users would get user-level permissions to Workplace Search:

PUT /_security/role_mapping/pki1_mapping
{
  "roles": [ "enterprise-search-workplace-search-user" ],
  "enabled": true,
  "rules": {
    "all": [
      {"field": { "dn": "*, OU=Example Company Users, DC=example, DC=com"}}}
    ]
  }
}

However, Example Company Admins would get admin-level permissions:

PUT /_security/role_mapping/pki1_mapping
{
  "roles": [ "enterprise-search-workplace-search-admin" ],
  "enabled": true,
  "rules": {
    "all": [
      {"field": { "dn": "*, OU=Example Company Admins, DC=example, DC=com"}}}
    ]
  }
}

« Set up Enterprise Search with OpenID Connect single sign-on (SSO) Set up Enterprise Search with LDAP user authentication »