Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Secrets as environment variables? #153

Closed
rmb938 opened this issue Mar 6, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@rmb938
Copy link

commented Mar 6, 2018

Expected Behaviour

Secrets can be mounted as volumes or used as environment variables

Current Behaviour

Secrets can only be mounted as volumes

Possible Solution

One solution would be making the function definition slightly more complex. An example would be

functions:
  myfunction:
    image: local/myfunction
    secrets:
      - name: my-secret1
         mount:
            location: /run/secrets/my-secret
      - name: my-secret2
         environment:
            key: my-secret-key
            location: MY_SECRET_2

This will mount all keys under my-secret1 at /run/secrets/my-secret and place my-secret-key from my-secret2 into the environment variable MY_SECRET_2

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.

Context

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.

Your Environment

  • Are you using Docker Swarm or Kubernetes (FaaS-netes)? Kubernetes
@alexellis

This comment has been minimized.

Copy link
Member

commented Mar 6, 2018

Current behavior

Secrets can only be mounted as volumes

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.

http://movingfast.io/articles/environment-variables-considered-harmful/

@alexellis alexellis added the question label Mar 6, 2018

@alexellis alexellis changed the title Secrets as environment variables Question: Secrets as environment variables? Mar 6, 2018

@rmb938

This comment has been minimized.

Copy link
Author

commented Mar 6, 2018

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.

@alexellis

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

So in that case let's mark the issue for #revisit and close out so the issue tracker is clear and still available via a Google search. When there is a clear usecase which prevents a function from running we can review again. Thanks for the suggestion

@alexellis

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

Derek add label: revisit

@derek derek bot added the revisit label Mar 7, 2018

@alexellis

This comment has been minimized.

Copy link
Member

commented Mar 7, 2018

Derek close: revisit if essential

@derek derek bot closed this Mar 7, 2018

@rmb938

This comment has been minimized.

Copy link
Author

commented Mar 7, 2018

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.

@alexellis

This comment has been minimized.

Copy link
Member

commented Mar 9, 2018

Hey @rmb938 here's a bit more context on the pros/cons of secrets as env-vars from Docker's security lead.

https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/

Also:

I don't think there ever will be a clear usecase

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.