Database credentials

Database monitoring needs a monitoring user’s credentials to read from the database. The agent supports three ways to provide them, so you can keep secrets out of your configuration. The automatic eBPF view of your queries needs no credentials at all. For the general flow, see the Database monitoring overview.

The three credential modes

Environment reference (default)

The credential is stored as a reference, not a value. The agent reads it from an environment variable on the host at runtime, so the plaintext value never reaches KloudMate or the stored configuration. This is the default and the recommended mode.

The agent also handles escaping for you, so a password with special characters works in a connection string without you having to encode it.

Plaintext inline

You can enter the value directly. It is then stored in the configuration. The interface shows a clear “stored unencrypted” warning, because the value lives in the configuration and on disk. Use this only when you accept that trade-off.

Operator-managed

The credential is still an environment reference, but you supply the environment variable yourself rather than through the wizard. This suits secrets that come from an external secret manager. How you supply the variable depends on the platform:

• On a virtual machine: set KM_SECRET_<name> for the agent, for example through the systemd EnvironmentFile.
• On Kubernetes: put KM_SECRET_<name> in a Kubernetes Secret and point the Helm release at it with the dbMonitoring.secretName value. See Database monitoring on Kubernetes.

Rotation

The reference modes store only a reference. So you rotate a database password by updating the environment variable or Kubernetes Secret on the host. The agent’s configuration does not change.

Note

On Kubernetes, the collector reads the Secret when its pod starts, so a rotated password takes effect on the next pod restart. See the ordering note in Database monitoring on Kubernetes.

Grants

Whichever mode you use, the monitoring user needs read access to the engine’s statistics. Some coverages need specific grants too, for example GRANT pg_monitor on PostgreSQL. The wizard shows the exact setup steps for the coverages you selected. See Engines and coverages.

Next steps

On a VM Set up monitoring on a host.

On Kubernetes Set up monitoring in a cluster.

Configuration model How credentials fit the managed config model.