Milvus database plugin HTTP API

The Milvus database plugin is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles against a Milvus 2.x cluster using the Milvus Go SDK (v2) over gRPC.

Configure connection

In addition to the parameters defined by the Database Secrets Engine, this plugin has a number of parameters to further configure a connection.

Method	Path
POST	/database/config/:name

Parameters

• url (string: <required>) – Specifies the Milvus gRPC server address, e.g. milvus.example.com:19530.

• username (string: "") – Specifies the root credential username OpenBao uses to authenticate to Milvus and issue/revoke dynamic users. Required unless token is set.

• password (string: "") – Specifies the root credential password corresponding to username. Required unless token is set.

• token (string: "") – Specifies an API token (e.g. Zilliz Cloud) to use instead of username/password. Either token, or both username and password, must be provided.

• db_name (string: "") – Specifies the default Milvus database name. If unset, Milvus uses its default database.

• ca_cert (string: "") – Specifies a PEM-encoded CA certificate (or bundle) to use when validating the Milvus server's TLS certificate.

• ca_path (string: "") – Specifies a filesystem path to a PEM-encoded CA certificate (or bundle) to use when validating the Milvus server's TLS certificate.

• client_cert (string: "") – Specifies a PEM-encoded client certificate to present for mTLS. Must be set together with client_key.

• client_key (string: "") – Specifies the PEM-encoded private key corresponding to client_cert. Must be set together with client_cert.

• insecure (bool: false) – Skips TLS certificate verification when connecting to Milvus. Intended for development only.

• username_template (string) - Template describing how dynamic usernames are generated. Milvus 2.4+ rejects usernames longer than 32 characters, so custom templates must stay within that limit.

Default Username Template

{{ printf "v-%s-%s-%s" (.DisplayName | truncate 8) (.RoleName | truncate 8) (random 10) | replace "." "-" | truncate 32 }}

Example Usernames:

Example
DisplayName	token
RoleName	myrolename
Username	v-token-myrolena-uszt1n4cyh

Sample payload

{
  "plugin_name": "milvus-database-plugin",
  "allowed_roles": "reader",
  "url": "milvus.example.com:19530",
  "username": "root",
  "password": "Milvus123"
}

Sample request

$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/database/config/milvus

Statements

Unlike SQL-style database plugins, this plugin does not use semicolon-separated statement lists. creation_statements is a single JSON document listing pre-existing Milvus role names to grant to the new user. For more information on configuring roles see the Role API in the database secrets engine docs.

The following are the statements used by this plugin. If not mentioned in this list the plugin does not support that statement type.

• creation_statements (string: <required>) – Specifies a single JSON document listing Milvus roles to grant and/or custom role definitions with privileges:

  {
    "roles": ["public"],
    "custom_roles": [
      {
        "name": "collection_reader",
        "privileges": [
          {
            "object_type": "Collection",
            "object_name": "Products",
            "privilege": "Search",
            "db_name": "default"
          }
        ]
      }
    ]
  }

  roles is an array of bare role name strings that must already exist on the cluster. custom_roles defines custom roles that are automatically created and granted privileges before assigning them to the user. On the wire the plugin ensures custom roles exist via CreateRole and Grant, creates the credential via CreateCredential, and then assigns each role via AddUserRole.

  If any AddUserRole call fails, the plugin deletes the just-created credential via DeleteCredential before returning the error, so no half-configured user is left behind. There is no built-in default; a role without creation_statements, or with a creation_statements that isn't a valid JSON role document, fails to issue credentials.

revocation_statements, rollback_statements, and root_rotation_statements are accepted by the database secrets engine framework but are not used by this plugin. Revocation always deletes the user via DeleteCredential. Password rotation (UpdateUser) is a no-op because Milvus requires the user's old password unless common.security.superUsers is configured.

Static roles

Static roles rotate the password of an existing Milvus user on a schedule:

$ bao write database/static-roles/svc \
    db_name=milvus \
    username=svc \
    rotation_period=24h