Question: Secrets as environment variables? #153
Secrets can be mounted as volumes or used as environment variables
Secrets can only be mounted as volumes
One solution would be making the function definition slightly more complex. An example would be
This will mount all keys under
This same solution could also apply for configmaps. I do know that Docker Swarm's Secrets and Configs are slightly different and a solution would have to be made that satisfies both runtimes.
Most cloud native apps use 12factor which recommends storing configuration (and optionally secrets) in environment variables. https://12factor.net/config It would be nice for functions to be able to follow those same standards.
This is as designed.
There are certainly some ways you can stuff secrets into an environmental variables without changing OpenFaaS.
What is your concrete use-case that means you need an environmental variable
As for 12factor - you can configure your application using environment but using environment for secrets is not a good idea. The point of using secrets is to provide an alternative to environmental variables which are liable to leak in trace messages etc.
I currently do not have a concrete use-case however I still think this is a feature that is needed.
I do understand that environment variables can be leaked through traces and various other means however on a trusted system those issues are not as big as a concern.
I don't think there ever will be a clear usecase that will "prevent a function from running". Custom functions can very easily be made to load things from files instead of environment variables.
I do have examples where environment variables are considered easier though. If we look at the library (specifically in Go but most languages are similar) for Consul (https://github.com/hashicorp/consul/blob/master/api/api.go#L293), it defaults to loading it's secret tokens from the environment. Yes one can very easily make a custom configuration object and pass in the token via a variable loaded from a file but it does take more work. Now this doesn't prevent a function from running but it does take more work for the function developer.
I have no problem writing up a proposal then contributing code to add this functionality once/if it's accetped. However being that it will touch so many different parts of the project, (changing the function spec, adding k8s and swarm support, ect..) I would like this to be seen as maybe not a feature that is strictly required but one that could be thought about.
Hey @rmb938 here's a bit more context on the pros/cons of secrets as env-vars from Docker's security lead.
We are Serverless Functions Made Simple - preferring convention over configuration - implementing code with no clear usecases should raise a red flag. Happy to revisit if this becomes a blocker for some key users and look into options.
Thanks again for sharing your ideas and opinions with the community.