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. Some definitions name their credential as optional (MySQL and MariaDB over the local socket, Redis, ClickHouse): the probe connects without one where the server allows it and uses the secret the moment you store it, so a server with no password set is measured with nothing to configure. A secret stored on a different machine (a cloned disk) is reported as "sealed on another machine", not as missing, because the ciphertext is bound to the machine it was written on.

SQL authentication modes

The definition picks the mode. There is no hardcoded password anywhere, and a password never appears on a child process's command line.

• 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. A missing strict secret fails loudly, never silently.

Optional credentials

Some definitions name an optional secret: if it exists it is used, if not the probe falls back to socket auth. The MySQL catalog works this way with the secret name mysql. A stock install needs nothing; a hardened box where root has a password gets full telemetry the moment you create a read-only user and store it:

wakora secret set mysql --user monitor

The failing check tells you exactly this command when the credential is what is missing.

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.