Secure your clusters with JWT

These steps show how you can secure your Elasticsearch clusters, and Enterprise Search instances in a deployment by using a JSON Web Token (JWT) realm for authentication.

The JWT credentials are valid against the deployment, not the ECE platform. You can configure role-based access control for the platform separately.

Before you begin

edit

Elastic Cloud Enterprise supports JWT of ID Token format with Elastic Stack version 8.2 and later. Support for JWT of certain access token format is available since 8.7.

Configure your 8.2 or above cluster to use JWT of ID Token format

edit

xpack:
  security:
    authc:
      realms:
        jwt: 
          jwt-realm-name: 
            order: 2 
            client_authentication.type: "shared_secret" 
            allowed_signature_algorithms: "HS256,HS384,HS512,RS256,RS384,RS512,ES256,ES384,ES512,PS256,PS384,PS512" 
            allowed_issuer: "issuer1" 
            allowed_audiences: "elasticsearch1,elasticsearch2" 
            claims.principal: "sub" 
            claims.groups: "groups"

	Specifies the authentication realm service.
	Defines the JWT realm name.
	The order of the JWT realm in your authentication chain. Allowed values are between `2` and `100`, inclusive.
	Defines the client authenticate type.
	Defines the JWT `alg` header values allowed by the realm.
	Defines the JWT `iss` claim value allowed by the realm.
	Defines the JWT `aud` claim values allowed by the realm.
	Defines the JWT claim name used for the principal (username). No default.
	Defines the JWT claim name used for the groups. No default.

By default, users authenticating through JWT have no roles assigned to them. If you want all users in the group elasticadmins in your identity provider to be assigned the superuser role in your Elasticsearch cluster, issue the following request to Elasticsearch:

POST /_security/role_mapping/CLOUD_JWT_ELASTICADMIN_TO_SUPERUSER 
{
   "enabled": true,
    "roles": [ "superuser" ], 
    "rules": { "all" : [ 
        { "field": { "realm.name": "jwt-realm-name" } }, 
        { "field": { "groups": "elasticadmins" } }
    ]},
    "metadata": { "version": 1 }
}

	The mapping name.
	The Elastic Stack role to map to.
	A rule specifying the JWT role to map from.
	`realm.name` can be any string containing only alphanumeric characters, underscores, and hyphens.

In order to use the field groups in the mapping rule, you need to have mapped the JWT Attribute that conveys the group membership to claims.groups in the previous step.

Configure your 8.7 or above cluster to use JWT of access token format

edit

xpack:
  security:
    authc:
      realms:
        jwt:
          jwt-realm-name:
            order: 2
            token_type: "access_token" 
            client_authentication.type: "shared_secret"
            allowed_signature_algorithms: [ "RS256", "HS256" ]
            allowed_subjects: [ "[email protected]" ] 
            allowed_issuer: "issuer1"
            allowed_audiences: [ "elasticsearch1", "elasticsearch2" ]
            required_claims: 
              token_use: "access"
            fallback_claims.sub: "client_id" 
            fallback_claims.aud: "scope" 
            claims.principal: "sub" 
            claims.groups: "groups"

	Specifies token type accepted by this JWT realm
	Specifies subjects allowed by the realm. This setting is mandatory for `access_token` JWT realms.
	Additional claims required for successful authentication. The claim name can be any valid variable names and the claim values must be either string or array of strings.
	The name of the JWT claim to extract the subject information if the `sub` claim does not exist. This setting is only available for `access_token` JWT realms.
	The name of the JWT claim to extract the audiences information if the `aud` claim does not exist. This setting is only available for `access_token` JWT realms.
	Since the fallback claim for `sub` is defined as `client_id`, the principal will also be extracted from `client_id` if the `sub` claim does not exist

Refer to JWT authentication documentation for more details and examples.

Update the trust settings of a deployment

edit

A deployment can be configured to trust all, specific, or no deployments in the same ECE environment, other remote ECE environments, Elastic Cloud, or self-managed environments.

This can be done in the Security page of your deployment:

Log into the Cloud UI.
On the deployments page, select your deployment.

Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.
From the Security menu, find the Trust Management section.

Trusted Environments at the Deployment Level

The page shows a list of all the deployments that this deployment trusts, grouped by environment. Initially only the Local Environment appears, which represents the current ECE environment, but you can trust deployments in other ECE environments, in Elastic Cloud, or any self-managed environment.

page, under *Security* > *Trust Management*:

Select Add trusted environment to configure trust with deployments in another ECE environment whose trust relationship has been created in the previous step.
For each trusted ECE environment you can edit the trust level to trust all deployments or just specific ones. For the specific ones option, you can introduce a list of Elasticsearch cluster IDs to trust from that ECE environment. The Elasticsearch Cluster ID can be found in the deployment overview page under Applications.

« Secure your clusters with Kerberos Deployment heap dumps »