Apache Druid database secrets engine

Apache Druid is one of the supported plugins for the database secrets engine. This plugin generates dynamic credentials against an Apache Druid cluster's BasicSecurity authenticator/authorizer, exposed through the Coordinator's druid-ext/basic-security REST extension. 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 Druid role names to bind to the new user, rather than a semicolon-separated list of statements. Under the hood the plugin creates the user in the configured authenticator (POST .../authentication/db/<authenticator>/users/<name>), sets its password (POST .../users/<name>/credentials), creates the matching user in the configured authorizer (POST .../authorization/db/<authorizer>/users/<name>), and then binds each listed role (POST .../users/<name>/roles/<role>). Druid's BasicSecurity extension must already be enabled on the cluster, and the roles referenced by creation_statements must already exist in the configured authorizer — this plugin does not create roles, only users and role bindings.

Capabilities

Plugin Name	Root Credential Rotation	Dynamic Roles	Static Roles	Username Customization
druid-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. The url must point at the Druid Coordinator:

   $ bao write database/config/druid \
       plugin_name="druid-database-plugin" \
       allowed_roles="reader" \
       url="http://druid.example.com:8081" \
       username="admin" \
       password="admin" \
       authenticator="MyBasicMetadataAuthenticator" \
       authorizer="MyBasicMetadataAuthorizer"
   Success! Data written to: database/config/druid

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

   $ bao write database/roles/reader \
       db_name="druid" \
       creation_statements='{"roles":["datasourceReadAccess"]}' \
       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

Druid-specific notes

• No root credential rotation: The plugin does not implement root credential rotation (database/rotate-root).
• BasicSecurity extension must already be enabled: This plugin does not bootstrap Druid's security configuration. The cluster must already have the druid-basic-security extension loaded, with the authenticator and authorizer names configured on database/config/:name (or the defaults, MyBasicMetadataAuthenticator / MyBasicMetadataAuthorizer) already defined in common.runtime.properties. Any roles referenced by creation_statements must already exist in the authorizer — this plugin only creates users and binds them to existing roles.
• url should point at the Coordinator: The BasicSecurity REST extension (druid-ext/basic-security/...) is served by the Druid Coordinator process, so url should be the Coordinator's base URL (for example http://druid.example.com:8081). The Router or Broker endpoints that clients use to run queries are separate from the Coordinator's security-management API.
• Partial-failure cleanup: Creating the authenticator user, setting its credentials, creating the authorizer user, and binding each role are four (or more) separate REST calls that are not transactional. If any call after the initial user creation fails — for example, an unknown role name — the plugin deletes the just-created authenticator user before returning the error, so no half-configured user is left behind.
• Idempotent deletion: Revocation deletes the user from both the authorizer and the authenticator; a 404 response from either is treated as success, so credential revocation is naturally idempotent.

API

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

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