Apache Solr database secrets engine

Apache Solr is one of the supported plugins for the database secrets engine. This plugin generates dynamic credentials against an Apache Solr cluster's Security Plugin API. It also supports Static Roles.

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

Unlike the SQL-style database plugins, creation_statements is a single JSON document listing pre-existing Solr role names to bind to the new user, rather than a semicolon-separated list of statements. Under the hood the plugin issues set-user against the admin/authentication endpoint (the Basic Auth Plugin's user table) followed by set-user-role against the admin/authorization endpoint (the Rule-Based Authorization Plugin) for each listed role. The cluster's Basic Authentication and Rule-Based Authorization plugins must already be enabled via security.json, and the roles referenced by creation_statements must already exist there — this plugin does not create roles, only users and role bindings.

Capabilities

Plugin Name	Root Credential Rotation	Dynamic Roles	Static Roles	Username Customization
solr-database-plugin	No	Yes	Yes	Yes

Setup

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

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

   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 OpenBao with the proper plugin and connection information:

   $ bao write database/config/solr \
       plugin_name="solr-database-plugin" \
       allowed_roles="reader" \
       url="http://solr.example.com:8983" \
       username="solr" \
       password="SolrRocks"
   Success! Data written to: database/config/solr

3. Configure a role that maps a name in OpenBao to a Solr role-binding document to execute to create the database credential. The roles listed must already exist in the cluster's Authorization Plugin configuration:

   $ bao write database/roles/reader \
       db_name="solr" \
       creation_statements='{"roles":["read-only"]}' \
       default_ttl="1h" \
       max_ttl="24h"
   Success! Data written to: database/roles/reader

Usage

After the secrets engine is configured and a user/machine has an OpenBao 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:

   $ bao read database/creds/reader
   Key                Value
   ---                -----
   lease_id           database/creds/reader/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
   lease_duration     1h
   lease_renewable    true
   password           SsnoaA-8Tv4t34f41baD
   username           v-token-reader-x7g2kf8s1a2b-1717000000

Solr-specific notes

• No root credential rotation: The plugin does not implement root credential rotation (database/rotate-root).
• Security plugins must already be enabled: This plugin does not bootstrap Solr's security configuration. The cluster's security.json must already have the Basic Authentication Plugin and the Rule-Based Authorization Plugin enabled, and any roles referenced by creation_statements must already exist in the authorization configuration — this plugin only creates users and binds them to existing roles.
• SolrCloud vs. standalone: The Security Plugin API endpoints (admin/authentication and admin/authorization) are exposed by both standalone Solr and SolrCloud deployments, so no special configuration is required to target either topology — point url at any node (or a load balancer in front of the cluster) that can serve the admin API.
• Partial-failure cleanup: set-user is not transactional with the subsequent set-user-role call. If the role-binding request fails (for example, a listed role does not exist), the plugin deletes the just-created user via delete-user before returning the error, so no half-configured user is left behind.
• Idempotent deletion: Solr returns a 200 response for delete-user even when the named user does not exist, so credential revocation is naturally idempotent.

API

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

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