Configure the keystore

Keystore configuration is a RESTful API-only feature that allows you to securely store Elastic Cloud Enterprise settings using the Elasticsearch keystore.

Before you begin

To configure the Elasticsearch keystore, you must meet the minimum criteria.

The minimum criteria include:

  • To access the RESTful API for Elastic Cloud Enterprise, you must have a bearer token, or you can use your Elastic Cloud Enterprise credentials.
  • The Elasticsearch cluster that you plan to configure must be version 6.0 or later.

For more information about the Elasticsearch keystore, refer to the Elasticsearch documentation.

Change the keystore string values

To change the string values, run the following command:

```
curl --request PATCH \
  --url https://ENDPOINT/clusters/elasticsearch/CLUSTER_ID/keystore \
  --header 'authorization: BEARER_TOKEN' \
  --header 'content-type: application/json' \
  --data '{
      "secrets": {
          "s3.client.CLIENT_NAME.access_key": {
            "value": "ACCESS_KEY_VALUE",
            "as_file": false
          },
          "s3.client.CLIENT_NAME.secret_key": {
            "value": "SECRET_KEY_VALUE"
          }
                }
    }'
```

Admin console endpoint for the API

ID of the cluster you want to configure

Bearer token for authentication

Value of the access key

Value of the secret key

The response includes the contents of the keystore after the operation completes:

```
{
        "secrets": {
                "s3.client.CLIENT_NAME.access_key": {
                        "as_file": false
                },
                "s3.client.CLIENT_NAME.secret_key": {
                        "as_file": false
                }
        }
}
```

The client name. You must use your own client name, and it must match the client name in the keystore.

Optional field. For this example, the default is false.

Note

Only the keys are shown, not the secret values.

The PATCH request is incremental. Keys specified in the request update to new values. When the value is missing, the key is removed. When the key is missing, it remains the same.

In the following example, the clientname is configured for a customer S3, or minio, repository:

```
PUT /_snapshot/s3-repo
{
  "type": "s3",
  "settings": {
    "bucket": "repositoryname",
    "client": "clientname",
    "base_path": "pathname"
  }
}
```

Change the keystore JSON file values

To change the JSON file values, run the following command:

```
curl --request PATCH \
  --url https://ENDPOINT/clusters/elasticsearch/CLUSTER_ID/keystore \
  --header 'authorization: BEARER_TOKEN' \
  --header 'content-type: application/json' \
  --data '{
    "secrets": {
      "gcs.client.CLIENT_NAME.credentials_file": {
        "value": {
          "type": "service_account",
          "project_id": "PROJECT_ID",
          "private_key_id": "PRIVATE_KEY_ID",
          "private_key": "-----BEGIN PRIVATE KEY-----\PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
          "client_email": "CLIENT_EMAIL",
          "client_id": "CLIENT_ID",
          "auth_uri": "https://accounts.google.com/o/oauth2/auth",
          "token_uri": "https://oauth2.googleapis.com/token",
          "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
          "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/test%10cloud-123456.iam.gserviceaccount.com"
        }
      }
    }
  }'
```

Admin console endpoint for the API

ID of the cluster you want to configure

Bearer token for authentication

Response:

```
{
        "secrets": {
                "gcs.client.CLIENT_NAME.credentials_file": {
                        "as_file": true
                },
                "s3.client.CLIENT_NAME.access_key": {
                        "as_file": false
                },
                "s3.client.CLIENT_NAME.secret_key": {
                        "as_file": false
                }
        }
}
```

The client name must be unique for each repository type, but it can be the same for s3 and GCS.

When the value is an object instead of a plain string, as_file defaults to true. To store all content as a string instead of a file, add "as_file": false. The GCS credentials should be stored in the file format.

Note

The response contains the previously added S3 keys.

Tip

To use GCS snapshots, the cluster must have the repository-gcs plugin enabled.

The request creates the credentials for the GCS repository:

```
PUT /_snapshot/s3-repo
{
  "type": "gcs",
  "settings": {
    "bucket": "users-snapshots",
    "base_path": "BASE_PATH_NAME",
    "client": "CLIENT_NAME"
  }
}
```

When you configure the keystore settings, the settings are automatically reloaded.

When you add an invalid key to the keystore, the instance bootloops. For a description of the invalid key error, go to the log. To correct the invalid key, use the get API to find the invalid key, then delete it.

Delete values from the keystore

For the value that you would like to delete, remove the value:

```
 curl --request PATCH \
  --url https://ENDPOINT/clusters/elasticsearch/CLUSTER_ID/keystore \
  --header `authorization: BEARER_TOKEN` \
  --header `content-type: application/json` \
  --data '{
      "secrets": {
          "key_to_remove": {}
      }
  }'
```

Admin console endpoint for the API

ID of the cluster you want to configure

Bearer token for authentication

Verify your credentials

If your credentials are invalid, an administrator can verify that they are correct by checking the keystore field in the cluster metadata.

If the credential values are correct, but are not working, the keystore file could be out of sync on one or more nodes.

To sync the keystore file: * Update the value for the key by using the patch API to delete the key from the keystore, then add the key again. * Rewrite the entire keystore on every node by removing the keystore element from the cluster data. Save your changes, add the keystore element back, then save again.

+ CAUTION: Use the second option only when necessary.

Note

It can take several minutes to update the keystore.