Environment variables specification should require _FILE variations to support reading from files

[kriswuollett]

What are you trying to achieve?

If an SDK supports environment variables, all of the environment variables should have a variation with a _FILE suffix so that the value can be read from a file instead of the variable itself. In some environments this would be extremely helpful where secrets are not allowed to be passed in an environment variable, e.g., for OTEL_EXPORTER_JAEGER_PASSWORD. Instead users should be able to point to a file specified by OTEL_EXPORTER_JAEGER_PASSWORD_FILE.

A use case that would probably be very common is mounting a Kubernetes Secret to a directory in a container. Besides actual secrets, Kubernetes users may access things like hostnames or ports within the same Secret, so supporting _FILE suffix for everything would remove the configuration burden of adding multiple configMapKeyRef and/or secretKeyRef references in Kubernetes workload resources. If all workloads reference the same ConfigMap and/or Secrets with the OTEL configuration values in their Namespace, then it makes it easier to have workloads set up similarly with less toil.

Additional context.

• Using secrets as files from a Kubernetes Pod
• Postgres, an example Docker image that uses the _FILE suffix convention for secrets
• Storing non-sensitive values like hostnames in a Secret

[kriswuollett]

Is this proposed change small, or does would it require making a proposal on https://github.com/open-telemetry/oteps?

[tigrannajaryan]

This should be likely covered by the config file.

[kriswuollett]

@tigrannajaryan, I do not consider it to be the same request as the config file proposal. It suffers from the issue that Kubernetes users would need to create a ConfigMap or Secret with the contents of the config file stored in a data field, and then map it to the container as a volume. It adds toil to the process because some external process whether runtime by an operator process or at deployment time by a script would need to pull secrets and config to generate the file. There also is the issue that devops may not want secrets merged into other config so they'd only be able to use a Secret.

On the other hand, if someone only needs to set a few properties, then having the implicit _FILE variation would be superior for environments that do not allow secrets to be passed directly in environment variables.

[tigrannajaryan]

What if the Otel config file supported a way to reference another file and fetch the value of a particular config setting from that other file?

[kriswuollett]

I'd expect that doing something similar with a _file variation for a value would be useful since the config file would mostly likely not be changed much. But I'd probably also ask if the environment variable name is the equivalent of the config file yaml path, then why not have it be generally supported?

Some software packages only support a _FILE suffix for things known to be secrets, but there could be exceptions to the rule like DigitalOcean's Container Registry that uses the auth token for both username and password, so I just wish there was a general convention to read a value from a file. If _FILE is too general such that it may cause naming conflicts, maybe _FROM_FILE.

An alternative, but not quite as convenient, would be just storing the secrets subset in another configuration file since the file would still need to be regenerated whenever the secret changes.

Perhaps there is someone with more experience than me from CNCF Kubernetes or a whitepaper from the same that could point to the best practices (for Kubernetes, or other similar cloud users).

[zeitlinger]

we've moved this to "not blocking stability", because there is a workaround: mount the config file from a config map secret

[svrnm]

@open-telemetry/technical-committee does this belong to the configuration project or should this be handled independently?

[tigrannajaryan]

This is tracked in Configuration Project Board and is in the purview of Config SIG. We do not need to involve the TC.

[tigrannajaryan]

@svrnm what's the right triaging label to apply to issues that are moved to a SIG?

[trask]

@tigrannajaryan sig-issue label that you applied is correct