Elasticsearch database secrets engine

Elasticsearch is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for Elasticsearch.

See the database secrets engine docs for more information about setting up the database secrets engine.

Capabilities

Getting started

To take advantage of this plugin, you must first enable Elasticsearch's native realm of security by activating X-Pack. These instructions will walk you through doing this using Elasticsearch 7.1.1.

Enable X-Pack security in elasticsearch

Read Securing the Elastic Stack and follow its instructions for enabling X-Pack Security.

Enable encrypted communications

This plugin communicates with Elasticsearch's security API. ES requires TLS for these communications so they can be encrypted.

To set up TLS in Elasticsearch, first read encrypted communications and go through its instructions on encrypting HTTP client communications.

After enabling TLS on the Elasticsearch side, you'll need to convert the .p12 certificates you generated to other formats so they can be used by Vault. Here is an example using OpenSSL to convert our .p12 certs to the pem format.

Also, on the instance running Elasticsearch, we needed to install our newly generated CA certificate that was originally in the .p12 format. We did this by converting the .p12 CA cert to a pem, and then further converting that pem to a crt, adding that crt to /usr/share/ca-certificates/extra, and using sudo dpkg-reconfigure ca-certificates.

The above instructions may vary if you are not using an Ubuntu machine. Please ensure you're using the methods specific to your operating environment. Describing every operating environment is outside the scope of these instructions.

Set up passwords

When done, verify that you've enabled X-Pack by running $ $ES_HOME/bin/elasticsearch-setup-passwords interactive. You'll know it's been set up successfully if it takes you through a number of password-inputting steps.

Create a role for Vault

Next, in Elasticsearch, we recommend that you create a user just for Vault to use in managing secrets.

To do this, first create a role that will allow Vault the minimum privileges needed to administer users and passwords by performing a POST to Elasticsearch. To do this, we used the elastic vaultuser whose password we created in the $ $ES_HOME/bin/elasticsearch-setup-passwords interactive step.

$ curl \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"cluster": ["manage_security"]}' \
    http://vaultuser:$PASSWORD@localhost:9200/_xpack/security/role/vault

Next, create a user for Vault associated with that role.

$ curl \
    -X POST \
    -H "Content-Type: application/json" \
    -d @data.json \
    http://vaultuser:$PASSWORD@localhost:9200/_xpack/security/user/vault

The contents of data.json in this example are:

{
 "password" : "myPa55word",
 "roles" : [ "vault" ],
 "full_name" : "Hashicorp Vault",
 "metadata" : {
   "plugin_name": "Vault Plugin Database Elasticsearch",
   "plugin_url": "https://github.com/hashicorp/vault-plugin-database-elasticsearch"
 }
}

Now, Elasticsearch is configured and ready to be used with Vault.

Setup

1. Enable the database secrets engine if it is not already enabled:

   $ vault secrets enable database
   Success! Enabled the database secrets engine at: database/
   

   Copy

   By default, the secrets engine will enable at the name of the engine. To enable the secrets engine at a different path, use the -path argument.

2. Configure Vault with the proper plugin and connection information:

   $ vault write database/config/my-elasticsearch-database \
       plugin_name="elasticsearch-database-plugin" \
       allowed_roles="internally-defined-role,externally-defined-role" \
       username=vault \
       password=myPa55word \
       url=http://localhost:9200 \
       ca_cert=/usr/share/ca-certificates/extra/elastic-stack-ca.crt.pem \
       client_cert=$ES_HOME/config/certs/elastic-certificates.crt.pem \
       client_key=$ES_HOME/config/certs/elastic-certificates.key.pem
   

   Copy

3. Configure a role that maps a name in Vault to a role definition in Elasticsearch. This is considered the most secure type of role because nobody can perform a privilege escalation by editing a role's privileges out-of-band in Elasticsearch:

   $ vault write database/roles/internally-defined-role \
         db_name=my-elasticsearch-database \
         creation_statements='{"elasticsearch_role_definition": {"indices": [{"names":["*"], "privileges":["read"]}]}}' \
         default_ttl="1h" \
         max_ttl="24h"
   

   Copy

4. Alternatively, configure a role that maps a name in Vault to a pre-existing role definition in Elasticsearch:

   $ vault write database/roles/externally-defined-role \
         db_name=my-elasticsearch-database \
         creation_statements='{"elasticsearch_roles": ["pre-existing-role-in-elasticsearch"]}' \
         default_ttl="1h" \
         max_ttl="24h"
   

   Copy

Usage

After the secrets engine is configured and a user/machine has a Vault token with the proper permission, it can generate credentials.

1. Generate a new credential by reading from the /creds endpoint with the name of the role:

   $ vault read database/creds/my-role
   Key                Value
   ---                -----
   lease_id           database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
   lease_duration     1h
   lease_renewable    true
   password           0ZsueAP-dqCNGZo35M0n
   username           v-vaultuser-my-role-AgIViC5TdQHBdeiCxae0-1602541724
   

   Copy

API

The full list of configurable options can be seen in the Elasticsearch database plugin API page.

For more information on the database secrets engine's HTTP API please see the Database secrets engine API page.