Secrets management
StackState Self-hosted v5.1.x
Last updated
StackState Self-hosted v5.1.x
Last updated
This document presents the concept of how secrets are managed in StackState using Agent V2 StackPack. You can find more detailed information on how to set up a security backend for or .
The Agent V2 can leverage the secrets package to call a user-provided executable to handle retrieval and decryption of secrets, which are then loaded in memory by the Agent V2. This approach allows users to rely on any secrets management backend (such as HashiCorp Vault or AWS Secrets Manager), and select their preferred authentication method to establish initial trust with it.
Use the ENC[] notation to denote a secret as the value of any YAML field in your configuration. Secrets are supported in any configuration backend (for example, file, etcd, consul) and environment variables.
Secrets are also supported in stackstate.yaml - Agent check configuration file. The Agent V2 first loads the main configuration and reloads it after decrypting the secrets. This means that secrets can't be used in the secret_* settings.
Secrets are always strings, which means that it isn't possible to set them to integer or Boolean type.
Example:
The above example presents two secrets: db_prod_user, and db_prod_password - these are the secrets' handles, and each of them uniquely identifies a secret within your secrets management backend.
Between the brackets, any character is allowed as long as the YAML configuration is valid. This means that quotes must be escaped. For example:
In the above example, the secret’s handle is the string {"env": "prod", "check": "postgres", "id": "user_password"}.
To retrieve secrets, you need an executable that can authenticate to and fetch secrets from your secrets management backend.
StackState Agent V2 caches secrets internally in memory to reduce the number of calls (convenient in a containerized environment). The Agent calls the executable every time it accesses a check configuration file that has at least one secret handle for which the secret isn't already loaded in memory. In particular, secrets that have already been loaded into memory don't trigger additional calls to the executable. In practice, this means that the Agent calls the user-provided executable once per file that contains a secret handle at startup, and might make additional calls to the executable later, if the Agent V2 or instance is restarted, or if the Agent dynamically loads a new check containing a secret handle.
Relying on a user-provided executable has multiple benefits:
Guaranteeing that the Agent doesn't attempt to load in memory parameters for which there isn’t a secret handle.
The ability for the user to limit the visibility of the Agent to secrets that it needs. For example, by restraining the accessible list of secrets in the critical management backend)
Freedom and flexibility in allowing users to use any secrets management backend without having to rebuild the Agent.
It enables each user to solve the initial trust problem from the Agent to their secrets management backend. The problem occurs in a way that leverages each user’s preferred authentication method and fits into their continuous integration workflow.
Set the following variable in stackstate.yaml configuration file: