MongoDB database secrets engine

MongoDB is one of the supported plugins for the database secrets engine. This plugin generates MongoDB user credentials dynamically based on configured roles, and 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, MongoDB's creation_statements is a single JSON document describing the authentication database and the roles to grant, rather than a semicolon-separated list of SQL statements.

Capabilities

Plugin Name	Root Credential Rotation	Dynamic Roles	Static Roles	Username Customization
mongodb-database-plugin	Yes	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/my-mongo \
       plugin_name="mongodb-database-plugin" \
       allowed_roles="readonly,readwrite" \
       connection_url="mongodb://{{username}}:{{password}}@mongo.example.com:27017/admin" \
       username="root" \
       password="secret"
   Success! Data written to: database/config/my-mongo

3. Configure a role that maps a name in OpenBao to a MongoDB role document to execute to create the database credential:

   $ bao write database/roles/readonly \
       db_name="my-mongo" \
       creation_statements='{"db":"admin","roles":[{"role":"read","db":"app"}]}' \
       default_ttl="1h" \
       max_ttl="24h"
   Success! Data written to: database/roles/readonly

   creation_statements is a JSON document, not a list of SQL statements:

   • db (optional, defaults to "admin") is the authentication database the user is created in.
   • roles (required) is an array of MongoDB role documents. Bare role names (no db) are flattened to plain strings; db-qualified roles are passed through as objects — matching what MongoDB's createUser command expects.

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/readonly
   Key                Value
   ---                -----
   lease_id           database/creds/readonly/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
   lease_duration     1h
   lease_renewable    true
   password           Bao-Mongo-1234567890
   username           v-token-readonly-3pfw6t8rvmc8mbkz8zef-1717000000

MongoDB-specific notes

• Write concern: write_concern on database/config/:name accepts JSON such as {"wmode":"majority","wtimeout":1000,"j":true} and defaults to {"wmode":"majority"} if unset. For CI systems that cannot pass literal braces, the value may be base64-encoded; the plugin tries base64 first and falls back to raw JSON.
• TLS and MONGODB-X509: Passing tls_ca enables TLS to the cluster. Additionally passing tls_certificate_key (a PEM-encoded certificate and key, concatenated) makes the plugin authenticate as the root user using the MONGODB-X509 mechanism instead of password auth.
• Static roles: Password rotation for static roles is performed with MongoDB's updateUser command. MongoDB has no native VALID UNTIL on users, so unlike some SQL plugins, lease expiry for dynamic roles is enforced purely by OpenBao revoking the lease (DeleteUser / dropUser), not by the database itself.

API

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

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