The Beats configuration files tend to contain a lot of credentials, which can be problematic if the configuration files are accidentally posted online or leaked in any other way. The Beats are already strict about the file permissions of their configuration file, refusing to start if the files are writable or readable by anyone else.
The next step in protecting these secrets is to store them in a separate binary keystore, where they are at least obfuscated (true encryption might be difficult to bootstrap).
We plan to follow the Elasticsearch model started in elastic/elasticsearch#22335. We aim to align as much as possible with ES at the user interface level, meaning similar commands to manage these key stores and a similar way of referencing them in the YAML files. The actual binary representation of the keystore might be different.
The Beats configuration files tend to contain a lot of credentials, which can be problematic if the configuration files are accidentally posted online or leaked in any other way. The Beats are already strict about the file permissions of their configuration file, refusing to start if the files are writable or readable by anyone else.
The next step in protecting these secrets is to store them in a separate binary keystore, where they are at least obfuscated (true encryption might be difficult to bootstrap).
We plan to follow the Elasticsearch model started in elastic/elasticsearch#22335. We aim to align as much as possible with ES at the user interface level, meaning similar commands to manage these key stores and a similar way of referencing them in the YAML files. The actual binary representation of the keystore might be different.