It’s always possible to set and use environment variables in the running environment for the Sensu backend and agent both the OSS and commercial binaries. In addition, many of the Sensu pipeline components (handlers, mutatators, checks, etc…) support configuration of
env_vars as a resource attribute.
In fact, what you try as an example in your handler is just a little off. You can’t reference a the value of an env_var to itself like that. I’ll show you why in an example below.
Setting up environment variables for Sensu to use
If you don’t want to put secrets in your monitoring configuration(because your hosting it in a git repo for example), then you can inject then into the running environment at backend start up. If using k8s, podman or docker you should be able to inject envvars into the running environment of the Sensu backend as per the normal process for those technologies. Or if you are using Sensu on a modernish linux distribution using systemd for managing the running backend you can instruct systemd to read in a file of envvars into the service environment. The service scripts in the commercial packages set this up already.
Let me share with you an example from my workstation using systemd.
Here’s my handler, all it does right now is report back the environment variables that the handler command has access to.
command: set |grep SLACK_ > /var/log/sensu/slack_environment.txt
Initially that’s nothing. But after I populate the file
and restart the sensu-backend service running under systemd… the handler output is different.
sudo cat /var/log/sensu/slack_environment.txt
Similar things are possible with k8s and docker. k8s in particular exposes some very useful secrets as env_vars in the running environment.For example k8s lets you set up a service account and exposes the necessary auth token that help you interact with the k8s api from inside a managed container. Any envars your container manager sets up at container startup are available just like what I setup in my systemd example above.
Sensu secrets at scale
Okay so you are probably asking yourself now, if I can do all this, why bother with the secrets management at all as a commercial feature?
The commercial Sensu secrets management feature is intended primarily to support Enterprise-scale secrets management using Vault (and other external secrets providers in the future). This is especially valuable in organizations that require strict secrets auditing, where operators aren’t allow to put sensitive information into the configs are even in group restricted config files on disk.
Sensu’s secrets are implemented to function like envvars to make it easier to transition from commercial version to OSS and back. Sensu commercial releases provide both an env and Vault secrets provider, but the env secrets provider is there primarily to help transition to something like Vault and to help prototype. You can use the env provider in a qa/testing for example and transition to Vault in production.
As an aside, the Sensu secret management implementation also provides a first class solution for secure distribution to agents, when mutual TLS is also enabled. But that’s a topic for a different day. If you are in an org that requires mtls you’re probably going to be requiring something like Vault anyways and won’t be allow to encode secrets directly.