So there are two concerns so far above, one is a security concern and the other is a desire to reload configuration options without restarting Telegraf. I think there is one other issue that is about segregating the passwords and storing them in a single shared location.

From a security point of view, I don't think the above helps. Telegraf would need permission to run the command and so it would be no different from reading the config file.

When it comes to not wanting to reload, the way I'd really like to solve this is by improving the reload flow to keep the output buffers and not interrupt running plugins that are not removed. This is quite complicated to do right and involves some work on top of the tgconfig experiment I worked on last year.

If the desire is to segregate passwords from the main config I recommend @phemmer method, create a file with environment variables, and then source it when starting the service. If you are using init you can source the file in /etc/defaults/telegraf and with systemd use the existing or add an additional EnvironmentFile.

If we improve reload, it won't allow environment variables to change of course, but I have been thinking adding some additional syntax to the config file to allow reading values from a file without needing multiple options. The design is inspired by curl and some other commands that use a @ to indicate it should be read from the file:

# set option using static string
bearer_token = "abcdef"
# or reading from a file
bearer_token = "@/etc/telegraf/bearer"

But what if you want to integrate with another secret store? The syntax above wouldn't solve that, and is probably a good argument against adding it. I think we could provide a layer similar the loader layer in the tgconfig experiment, and we might be able to leverage this to do some discovery tasks as well, but I think it is a large amount of work which I don't have time right now to experiment with. I think I would rather not make this addition until the config experiment can be integrated into Telegraf with the functionality it has now.

One more thing about the vSphere plugin in particular, I think the best action we could take for security would be to document a way to setup a limited privilege account that can be used to monitor the server.

Hide passwords in Telegraf config #3124

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions