IssueTracker

This issue is due to close in the next few days.  Are options #3 or #4 adequate features to meet your needs?

Option #4 is best of these. Really can't put things like passwords in to package.json due to storage in github, etc.

Richard

You report was forwarded to the engineering team.  Any questions, concerns or status updates will be posted here.

Thank you very much for bringing this to our attention!

A way to set env vars from the Cloud Platform Console UI would also be super neat.

If I may also add a requirement: encrypted environment variables.

Simple example: you need to make an API request from within the cloud function which requires some auth credentials. Obviously you don't want to have those env vars lying around in plain text.

Thanks a lot
Nicola

Is this coming anytime in the near future ?
Not being able to pass sensitive data to cloud functions renders them useless in many cases.

Wanted to follow up on this to get an idea of scheduled release. As mentioned, passing sensitive information via package.json or a hard config file aren't good options as they'd be exposed in Github/Cloud source/etc. An alternative option is to read data from Compute Metadata into the environment. We could do this manually via GET requests, yes, but that's a lot of overhead for each triggered function.

This is absolutely on the roadmap, although we don't yet have a concrete release date we can share.

I'd like to add to this, as I don't see it in the current comments, it would be wonderful to set these from the cloud console. The use case here is we are building functions that should be able to span multiple projects as reusable modules. The ideal workflow is, link each project's deployment of that function to github for automated deployments and have the console configuration pick it up. See Heroku, AWS beanstalk, or any other PaaS service for an example.

- Create a reusable function in github, say to send an email or slack with slack/sendgrid credentials as env variables.
- Add the git repo to GCF for deployments on a per project basis.
- Configure the function on the cloud console UI to have the slack/sendgrid credentials on a per project basis.
- Updates to the function go to one git repo and are deployed to all projects that use it.

Adding to my last comment, this would also allow us to create extremely shareable functions that, hopefully, would benefit the community at large. A function as described above, for example could be useful to a lot of people.

If Cloud Functions for Firebase have a solution for this, is there any reason something similar can't be done for regular cloud functions?

Another suggestion: different default service-account per cloud-function.
Right now the default service-account is shared among all cloud functions (and app-engine), which is bad for security. Cloud Functions could be great for security separation - i.e. each function using its own credentials/passwords.
Obviously I could upload the service-account auth-key with the code, but then it could be traced in the storage buckets.
I could also encrypt the service-account auth-key it with a kms-key that belongs to the default service-account, but then the security separation is broken (all Cloud Functions in the same project would have access to the kms-key that decrypts the service-account auth-key).

A unique service-account per cloud-function could be great for security separation.

We use the KMS work around to keep secrets out of code, since we'd otherwise have to hardcode them in the cloud function. The suggestion to keep *each* function in it's own Project isn't viable, given the high overload of cross project IAM wireup and all the non-documented edge cases (lost a few days digging them up). Overall, it's the most severe Cloud Functions flaw that keeps us from using Cloud Functions seriously. Hopefully it will be fixed soon.

I agree with #15. Separating each function to its own project is a bad design and hard to maintain. Each cloud-function should have its own default service account, so by configuring the KMS we could let one function access a specific KMS key without letting other cloud-functions access that KMS key.

Obviously this should be configurable - users who don't want to separate the functions could choose that all cloud-functions use the same default service-account (the app-engine default service-account).

Hi folks,

I'm going to do a batch update of some questions posed herein, which I hope will help shed some light.  The good news is... "yes".. to all (most?) of this and we're working on it; but we're just not there yet.

Environment Variables:
Customers (you) should be able to set key/value data pairs, attached to a function, at deploy time, and in scope at runtime without any special SDKs (like.. you know.. in the "environment")

Security & Permissions:
Customers should be able to assign arbitrary service accounts, and or arbitrary IAM roles (including custom roles) to a function

Deployments (from Github et. al):
Customers should be able to deploy functions directly from popular source repositories like github.  Optionally, customers should be able to trigger a re-deploy based on specific events emitted by these repositories (e.g deploy on commit)

Now some of these have gnarly edges, like privilege escalations emerging from arbitrary service account/IAM assignment, tendency to store "secrets" in the environment and auto-deploys without a corresponding CI/CD story or staged rollouts etc. Also it's not always clear how much should be specific to Cloud Functions vs generalize to Cloud Platform (or beyond).  The point of me posting this is simply to say.. "yes".. we hear you.

Disclaimer:  Nothing here corresponds to a promise or guarantee of exact feature scope, nor any implied timeline for delivery :)

FYI http://docs.aws.amazon.com/lambda/latest/dg/tutorial-env_console.html

So... sorry I'm late, but:  https://bit.ly/2FvvW8e

Hi google