Keystore

Applicability

• Supported clusters: This feature is available only for clusters that use the v3 deployment architecture.

  The v3 deployment architecture offers significant improvements in feature updates, system stability, and security. If your cluster uses the v2 deployment architecture, you can upgrade it to the v3 deployment architecture by following the instructions in Instance Architecture Upgrade.

• Feature availability: This feature is available by allowlist. If the Keystore Settings section is not visible in the console, contact technical support to enable it.

• Supported use cases: This feature currently supports security configurations for identity authentication using Active Directory and LDAP. In Elasticsearch, it serves the following purposes:

  • Integrate your Elasticsearch cluster with your existing enterprise authentication system, allowing users to log on to Elasticsearch directly by using their Active Directory or LDAP accounts.

    Active Directory (AD) is a directory service from Microsoft that centrally manages network resources such as users, computers, and group policies. Lightweight Directory Access Protocol (LDAP) is a cross-platform protocol for accessing and maintaining distributed directory information, such as user accounts and organizational structures.

  • Centralize permission management and avoid maintaining separate user credentials in Elasticsearch.

Configure and apply Keystore secrets

Step 1: Prepare YML configuration

• Purpose: To ensure Elasticsearch can correctly identify and use secrets stored in the Keystore.

  Some security settings must first be configured in the YML file. Otherwise, the cluster will fail to restart after you apply the Keystore settings.

• Example:
  To use the Keystore to configure the bind password for the LDAP realm my_ldap, you must first define the basic configuration for the my_ldap realm in the YML file.
  

  xpack.security.authc.realms.ldap.my_ldap:
    order: 0
    url: "ldap://your-ldap-server:389"  # LDAP server address
    bind_dn: "cn=admin,dc=example,dc=com"  # Administrator account
    user_search.base_dn: "ou=users,dc=example,dc=com"  # User search path
     # ... Other required parameters (such as certificates, group mappings, etc.)

Step 2: Configure Keystore secrets

1. Log on to the Alibaba Cloud Elasticsearch console. In the left-side navigation pane, go to Configuration and Management > ES Cluster Configuration.

2. Click Modify Configuration to edit the Keystore settings.

3. In the new row that appears, click the Key column to select or enter a key. The key prefix is fixed; you only need to edit the variable part as prompted (for example, replace a placeholder like with your actual realm name). In the Secret column, enter the secret, such as a password. For security, the input is masked with asterisks.

   Configuration details:

   Parameter	Description	Use case	Configuration
   Active Directory	Stores the encrypted password of the AD service account used to securely connect to an Active Directory domain controller.	The cluster uses this account to bind to the AD server when it needs to query user or group information.	Version 7.x and later: xpack.security.authc.realms.active_directory.<my_ad>.secure_bind_password Version 6.x: xpack.security.authc.realms.active_directory.secure_bind_password Replace <my_ad> with your realm name.
   LDAP	Stores the encrypted password of the LDAP service account used to securely connect to an LDAP server, such as OpenLDAP.	The cluster uses this account to retrieve user identities and group permissions from the LDAP directory.	Version 7.x and later: xpack.security.authc.realms.ldap.<ldap1>.secure_bind_password Version 6.x: xpack.security.authc.realms.<ldap1>.secure_bind_password Replace <ldap1> with your realm name.

4. Click OK. The system begins to apply the configuration and restart the cluster. You can monitor the restart progress on the task management page.

   Forced Change: This option is disabled by default. If enabled, the system skips the cluster health check and triggers a forced restart. This action can cause a prolonged service interruption; recovery time depends on the data volume. Use this option only for emergency changes when the cluster is already unavailable.