Advanced Sensu token evaluation

Sensu Go
1

I know that you can add label definitions to a Sensu client configuration and use those within a Sensu check for custom check command arguments. I also understand that each Sensu check must have a unique name. I also know that you can redact a value in a configuration file.

I have the use case where I want to use a single Sensu check definition against multiple hosts and apply a password argument to groups of hosts without embedding the password in the host configuration. I was wondering if there was a way, I could use a client label key (e.g. 'hostgroup -> windows) as part of a lookup of a custom check attribute (e.g. 'windows/password->“mypassword”) and embed that into the check command line definition.

If any of my assumptions or statements above are incorrect, feel free to correct me.

-Kendall Chenoweth

2

Hi @KendallChenoweth

Token substitution only works with the entity definition, meaning you can’t access the check labels, only the entity labels.

You could, however, achieve something relatively similar with the check’s env_vars attribute. For example, you would first need to add the hostgroup label to your entities, so it looks like this:

{
  "type": "Entity",
  "api_version": "core/v2",
  "metadata": {
    "labels": {
      "hostgroup": "windows"
    },
    "name": "my_entity",
    "namespace": "default"
  },
  [...]
}

Then, in your check definition, you would need to add the correspond environment variable in env_vars. Finally, in the check’s command, you would concatenate the environment variable using the value of the hostgroup label:

{
  "type": "CheckConfig",
  "api_version": "core/v2",
  "metadata": {
    "name": "my_check",
    "namespace": "default"
  },
  "spec": {
    "command": "echo ${{ .labels.hostgroup }}_password",
    "env_vars": [
      "windows_password=P@ssw0rd!"
    ],
    [...]
  }
}

In our example, we are just printing the environment variable so the event output would look like this:

$ sensuctl event info whisky.local check-token-entity

=== whisky.local - check-token-entity
Entity:    my_entity
Check:     my_check
Output:    P@ssw0rd!
[...]

The only downside I can see with that approach is that you can’t redact the check attributes so this password would be exposed via the API and the log entries. This is why adding the passwords within the entities labels is always the best solution.

Let us know if you have any question.

1 Like