1. Introduction
With the password store, Checkmk can separate password management from their actual use.
Prior to version 2.5.0, passwords stored there could be passed in plain text to special agents or active checks.
In addition, a non-public API was available.
This is now supplemented by an initial draft (v1_unstable) of a public API.
This gives all extension developers the ability to have a special agent or active check read passwords directly from the store.
Incidentally, starting with Checkmk 2.5.0, the password store is also active in the background when you mark a password as Explicit. You can therefore work with the same programming interfaces without needing to know how the password in use is actually being managed.
Some of the programming interfaces presented here are marked as |
1.1. Scope of the examples shown
In this article, you will learn how to use secrets stored in the Password Store through two examples:
Ideally, you are developing your own special agents or active checks for which the performance of Python 3 is sufficient and that run under Checkmk starting with version 2.5.0. In this case, use the programming interfaces defined in
cmk.password_store.v1_unstablein the special agent or active check. These interfaces are used to pass a reference to the password store and the ID of the password to be looked up.In some cases, it is not possible to use Python 3. Or a special agent or active check must be executable under other monitoring systems or older versions of Checkmk. Or, an active check already exists and you simply need to create an invocation configuration for running it. In such cases, you can pass the password in plain text as a command-line argument. Additional measures may be necessary here to prevent the password from being read from the process list.
For illustrative purposes, both examples use a simple local check that outputs the passed password in the service description. The local check has the advantage that you do not need to write another check plug-in. Both examples thus require only three files.
We will not provide a detailed description in this article of how and after which customizations Checkmk services must be restarted. Please refer to the article on developing special agents for this information.
2. Secure handover of references
In case your special agent or active check only is required to operate under Checkmk (2.5.0 or higher), it is possible to securely hand over a reference to an object in the password store.
In that case, the programming interfaces defined at cmk.password_store.v1_unstable are available to your program.
With the reference to the object in the password store, your program can then retrieve the password itself.
In this example, we show a basic special agent that requires three sample files. If you want to reproduce the example, first create three folders:
2.1. The special agent
In the special agent, you import the following three items:
an extension for
argparse, namelyparser_add_secret_option,the function
resolve_secret_option, which is used to retrieve the password,and finally the class
Secret, which serves as a container for the confidential data.
First, you create the parser for command-line arguments.
Use parser_add_secret_option to add the Checkmk-specific extension for passing the reference to the password store.
The key point:
This creates two possible arguments—not only the expected one (here, --secret for handing over a password), but also a second one (--secret-id) for passing the reference.
For the following two tests, it is important that you have switched to the site user using |
The command-line invocation displays the two options that were created, --secret and --secret-id:
For command-line tests, use the --secret option and pass the password in plain text:
In the next two sections, we’ll demonstrate how to pass references.
2.2. Form and rules for configuration
Via cmk.rulesets.v1.form_specs and link: cmk.rulesets.v1.rule_specs you can define the form visible in the setup and the corresponding rule configuration.
After you have saved this file and restarted Checkmk, you can configure the rule for Hello password! with exactly one field: either a password stored in the Password Store or an explicitly specified password.
For the purposes of this article, the distinction is irrelevant; the method of passing the value, which will be shown later, is always the same.
For further testing, you should create a separate host to which you assign only the Hello password! special agent and nothing else.
Throughout the rest of this article, the name testhost will be used for this host.
2.3. Invocation configuration
The invocation configuration brings everything together.
When generating the command-line parameters, --secret-id is used.
The parameter params['password'] is implicitly converted to a reference to the password store:
If you want to see how the reference is passed, just try running cmk -v -D testhost:
In the highlighted command line, you can see the reference separated by a colon.
The first parameter is the UUID of the password to be retrieved; the second is the path to the password store to be used.
Finally, when you view the service details for the Hello password service on your host testhost, you will see the password stored in the password store and revealed using secret.reveal().
3. Insecure handover of passwords
Choose this method only if, for example, you need to support other monitoring systems or older versions of Checkmk.
Passwords handed over in plain text are visible in the process table!
On Linux, any program can use the function |
In this example, we’ll also demonstrate a minimal special agent that requires three sample files. If you want to reproduce the example, first create three folders:
3.1. Special agent
For this example, we’ve prepared a special agent as a simple shell script. The agent simply displays all of the command-line arguments passed to it:
3.2. Form and rules for configuration
The form and the rules are the same as in the example above, except for the changed name of the plug-in family:
3.3. Invocation configuration
The invocation configuration differs from the example shown above in a few important details.
By convention, when generating the command-line parameters, --secret (or --password, in any case without an appended id) is used.
The unsafe() method of the Secret object in (params['password'].unsafe()) now ensures that the password is read in plain text for the program invocation:
In the output of cmk -v -D testhost, Checkmk masks the password passed in plain text:
If you are using an active check from a third party (for example, from the Monitoring Plugins Collection), you should verify whether the check uses setproctitle().
For active checks or special agents that were developed for Checkmk prior to 2.5.0, and which are implemented in Python, it is often worth converting them to the secure method described above.
If neither of these options is possible, ensure that only a small group of people can view the process list and that intercepted passwords cannot be abused.
