feat(outputs.nats): Add secret-support for credentials

[w1ll-i-code]

Summary

This PR adds a new config option credentials_bytes to the nats output, to make it easier to distribute the credentials directly with the config file, or with a secret store.

Checklist

• No AI generated code was used in this PR
• AI generated code used in this PR follows the InfluxData Policy on AI-Generated Code Contributions

Related issues

resolves #18047

[mstrandboge]

Thanks for the PR!

[srebhan]

Hmmm why can't we just convert the Credentials setting to config.Secret?

[skartikey]

@w1ll-i-code Thanks!

[srebhan]

@w1ll-i-code would it be possible to convert the existing credentials setting to a secret and check if it is a file first? Adding another option might confuse the user and creates all sorts of issues due to the redundancy, e.g. what happens if a user specifies both...

[w1ll-i-code]

@srebhan Initially I was considering that as well. I personally think it will be less confusing having a different option for it, then have an option that could be a path, a string or a secret. Also, would it then be possible to distribute the file-path as a secret?

I think since we already have that legacy feature, it'd be better to just document the behavior appropriately, in both the readme and the example config.

As for the redundancy issue, we already have the same with the username/password and credentials. Right now this does not seem to be handled at all. I could add a check before, that only one pair of credentials is configured?

[srebhan]

@w1ll-i-code to be honest I'm not sure about the two options. In the long-term I want to drop the file support as it could be easily replaced by a secret-store... With adding the procedure would be

1. add the additional credentials_bytes option
2. deprecate the file option
3. remove the file option after deprecation period
4. add back the credentials options and deprecate the credentials_bytes option (aka rename the option)
5. remove the credentials_bytes option after deprecation period

Contrary to converting the existing option to a secret the procedure would be

1. convert credentials to a secret and deprecate the file handling with
   1.1. reading the secret and test if the content is a file
   1.2 if the secret points to a file, use the file content as crenentials and
   issue a deprecation warning that support for files will be removed
   1.3. otherwise, directly use the read secret as credentials
2. remove file handling after deprecation period

My concern is that credentials means something to the user, credentials_bytes doesn't mean anything to the user! It's not clear from the name what it does. We do have other plugins with this issue as well having token and token_string or similar and we get questions about those on a regular basis...

[w1ll-i-code]

@srebhan Thanks for the reply. Do you have a tip for me how I should handle the deprecation? The credentials for nats should have the following format (from an example user I created for nats):

-----BEGIN NATS USER JWT-----
eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiIyNTVNVExOUkxYUUlIQU9XN0FWNlJSQkZXSTNSRVhWQVBNNEVESU4yRVJDMlRDNlJOTVdRIiwiaWF0IjoxNzYzOTA5MzAxLCJpc3MiOiJBQUZSSVlRNUVUTExOTUpFTkoyT0tGQjZVVVVKTkxGTkRFU0ZPMlpHVk41M01STTNWV1g0UUNUTyIsIm5hbWUiOiJyZWFkZXIiLCJzdWIiOiJVQ0o3VDJKTzRJNFBBNUFBTkhNWVJVT1pJV1pDVUtYN0dYNzJQVE5HVzI0QjZQWjRXNU5YVENPUCIsIm5hdHMiOnsicHViIjp7fSwic3ViIjp7ImFsbG93IjpbImljaW5nYV90ZWxlZ3JhZi5cdTAwM2UiXX0sInN1YnMiOi0xLCJkYXRhIjotMSwicGF5bG9hZCI6LTEsInR5cGUiOiJ1c2VyIiwidmVyc2lvbiI6Mn19.7RqxDDETvt7EwBTkat8fC_4XWgfBp3mkmOtyx_Op-H2vowVd9SE8OhnEzz5WvnBSfQkKbCAio8Bwb65vAFkmDQ
------END NATS USER JWT------

************************* IMPORTANT *************************
NKEY Seed printed below can be used to sign and prove identity.
NKEYs are sensitive and should be treated as secrets.

-----BEGIN USER NKEY SEED-----
SUAMPLIDZDI5LZHAPSUMWQ7TEQOVS2LXWSNJINTAA7UXXUELP5GZPZBISE
------END USER NKEY SEED------

*************************************************************

So we can probably use a quick check whether it contains any number of features from that format (e.g. newlines, or one of the header strings) and if it doesn't treat it as a file?

Also, should and can I add a comment for the deprecation or is there a longer procedure that should be followed? I am willing to help implement this, but I'd like some pointers into the right direction, as to not waste everyones time.

[srebhan]

I would simply os.Stat the content of the credentials setting, if errors.Is(err, os.ErrNotExists) I'd use the value as the actual credential otherwise I would read the file and print

n.Log.Warn("Using a file for 'credentials' is deprecated since v1.37.0 and will be removed with v1.40.0! Use a secret-store instead to securely handle your credentials.)

or similar.

[w1ll-i-code]

@srebhan Thanks, fixed it up. Took me a second to understand how to properly handle the error, but here you go. Hope this works better for you know. Lmk if I can fix anything else.

[srebhan]

@w1ll-i-code looks good from the structure! Some more comments...

[srebhan]

@w1ll-i-code I took the liberty to push my last comments so we can include this PR in the feature release planned for Monday...

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 Click here to get additional PR build artifacts

Artifact URLs

. DEB	. RPM	. TAR . GZ	. ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

[w1ll-i-code]

@srebhan Thanks, I was just about to address them.