Feature Request: First class Kubernetes secret files support

[jmealo]

Is your feature request related to a problem? Please describe.
To avoid adding secrets to environment variables. Kubernetes provides secrets that mount as files. Explicitly supporting this could help users of node-config improve their security.

Describe the solution you'd like
node-config explicitly provided secret support for Kubernetes/external secrets with documented examples (possibly via something like customEnvironmentVariables, except for secrets files?)

Describe alternatives you've considered
You can export these secrets to environments and use customEnvironmentVariables to map them to node-config values. Ideally, files could/would be used though so that enumeration of process.env by an attacker doesn't expose secrets.

Please tell us about your environment:

• node-config version: 3.3.9
• node-version: 18.12.1

Other information
https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume

[markstos]

I'm closing this because it can implemented externally to the core project: Write some software which reads the Kubernetes secret volume format and loads it environment variables or a JSON file which can be understood by node-config.

It's not reasonable for a tiny team to support in-core all the different possible secret storage solutions.

[jmealo]

Understood. I think you've missed the point of loading from volumes versus environment variables though? It's a security issue not a convenience thing. It would need to be built in to have better security.

For those looking to keep secrets out of their environment variables you could have a wrapper script write your secrets to a node-config compatible file format and source that. It's an extra step but will achieve the same thing.

All you need is a vulnerability in one package that can enumerate process.env and your secrets go public. That's why people keep secrets out of the env. Provided links in original issue elaborate on this further from a k8s perspective.

Thanks for the work your small team does.

[markstos]

All you need is a vulnerability in one package that can enumerate process.env and your secrets go public. That's why people keep secrets out of the env. Provided links in original issue elaborate on this further from a k8s perspective.

... or all you need is a vulnerability in one package that can read the volume that stores the secrets in the k8s format. How is that more secure? If there is an insecure dependency, it has access to whatever the process has access to, whether it's a filesystem path or process.env.

This area was discussed in 2015 #190 where we considered deleting process env values after we loaded them... but it turns out the values are persisted under /proc, so that doesn't add much value.

In #602 there was discussion of adding support for marking values as sensitive so that we dumped out the config file values, those values would be masked in some contexts.