Is it possible to hash passwords in Splunk OTEL agent_config.yaml?

[sh_v]

Hi all, 

I am wondering if it is possible to store a hashed value for passwords which are required for some of the receivers?

Some receivers, especially database related ones, will require username and passwords to connect and collect measurement data, and I do not feel safe saving passwords in plaintext in agent_config.yaml. 

[sh_v]

Yeah, I meant storing the passwords in encrypted form, akin to secrets within kubernetes, as it will put another layer of security, since the attacker will need to spend resources to decrypt it. 

[PickleRick · Accepted solution]

I don't know Kubernetes that well but if it's in any way similar to Ansible's Vault, you have to provide password for the vault every time you want to use vault-stored credentials. That makes sense. If you the credentials are decrypted automatically, it makes no real difference if you store the credentials in plain-text form or in encrypted form along with the secret used for encryption. It just makes it a slightly bit more inconvenient but that's it.

[PickleRick]

Hashing wouldn't work. Hashing by definition is a one-way function which does not let you calculate the original value of the hashed string so hashed password would be useless for you. You use hashing (preferably with salt) if you want to be able to verify if the supplied value is correct or not without the need of knowing (and storing) the correct value itself.

In general, to be able to use the credentials you have to store them in a form that allows you to retrieve them in plain-text. So even if you have them in an encoded/encrypted form you must be able to decode/decrypt them before use so you have to either provide a secret used to decrypt the credentials manually at each start (like password for private keys at apache httpd start) or have to store the secret along with your config somewhere (like you have in splunk config). From a security standpoint it's not that big a difference - you just need one extra step to exfiltrate such credentials.

Anyway, you should rather focus on:

1) Limiting access to the configuration and

2) Providing the agent with credentials for minimum needed access accounts (like monitoring-only database user and not the full dbadmin).