Skip to main content

Secrets and credentials

Some probes need credentials: a database monitor user, an SNMP community or v3 passphrase, an HTTP basic-auth login. The rule is absolute: those values live on the host, encrypted, and never travel to the server. A definition references a credential by name, and the agent resolves that name locally at probe time.

Setting a secret​

The canonical path is the CLI on the host:

wakora secret set mysql-monitor --user monitor

You are prompted for the password with no echo. For automation you can pipe it in on stdin. The value is stored as machine-bound AES-GCM ciphertext in /etc/wakora/secrets.conf (0600), with no plaintext on disk.

Manage them with:

wakora secret list
wakora secret rm mysql-monitor

How a definition uses it​

A SQL probe references the credential by name:

{ "type": "sql", "driver": "mysql", "secret": "mysql-monitor", "query": "..." }

At probe time the agent looks up mysql-monitor locally, builds the connection string on the box, and runs the query. The value never appears in the definition and never leaves the host. If the secret is missing, the probe fails with a clear "run wakora secret set" message rather than silently.

SQL authentication modes​

The definition picks the mode. There is no hardcoded password anywhere.

  • Socket, no password. "socket": true with "user": "root" uses the local unix socket. This is the default for local MySQL, MariaDB and PostgreSQL, and works out of the box on a typical Debian or Ubuntu root@localhost setup. On Windows MSSQL, "socket": true means shared memory (the configless local default).
  • Credential over TCP. "secret": "name" connects over TCP with the credential from the local store. Use this for remote or password-protected databases, or a least privileged monitor user.

SNMP credentials​

For SNMP the community string (v2c) or the USM user and passphrases (v3) are secrets and stay local:

wakora secret set snmp-switch                 # v2c community
wakora secret set snmp-ups-v3 --user upsmon --priv   # v3 auth + privacy

Non-secret v3 parameters (auth and privacy protocol, context) ride in the signed definition. The credential does not. On a collector pair, set the secret on both the primary and the backup collector, because secrets are never transferred between hosts.

What the server sees​

Metrics and service names, never a password. This local-only secret model is a compliance edge a cloud SaaS structurally cannot match, and it is one of the reasons the agent is built the way it is.

Planned

A console option to enter secrets in the browser with client-side encryption (the browser encrypts under the host key, the server only ever sees ciphertext) is planned. Today the paths are the CLI, install flags reading from stdin, env or file, and a reference to an existing host secret store.