Secret security

Secrets hold the most sensitive data you give Onagre: database and broker credentials. This page explains how they are protected, from the moment you save them to the moment an agent uses them.

At rest: two levels of keys#

• Each organization has its own organization key, a random 256-bit key. Your secrets are encrypted with it using AES-256-GCM, an authenticated encryption that guarantees both confidentiality and integrity.
• The organization key is itself encrypted by a platform master key, kept in a dedicated secret store, never in the database. Master keys can be rotated.

A copy of the database alone is therefore not enough to read a secret, and one organization's key gives no access to another organization's secrets.

In the interface: write-only#

A secret's value is never displayed or returned after it is saved: the list shows its code, type and version only. To change a value, you replace it with a new version. Only Managers and Admins can see the list of secrets and manage them.

In use: decrypted only to run a check#

When a sensor that uses a secret is due, the Hub decrypts the latest version and sends it to the private agent that runs the check, inside the agent's TLS-encrypted connection. The agent uses it in memory to connect, and never writes it to disk.

Only your organization's private agents receive your secrets: they never go to the public agent or to another organization's agents.

Variables are not secrets#

Variables are stored and displayed in plain text, by design. Keep credentials in secrets.

Your part#

• Give sensors read-only database and broker accounts, limited to what the check needs.
• Restrict the Manager role to the people who must handle credentials — see Team and roles.
• When someone leaves or a credential leaks, change the password on the database side, then Update value in Onagre.