.env-based secret param binding for Functions#10714
Conversation
…e params right now
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
Berlioz
force-pushed
the
vsfan_env_params_use
branch
from
14c6bec to
d479b2d
Compare
| "^" + // start of string | ||
| "csm:\/\/" + // scheme csm:// | ||
| "([a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)" + // secret ID is a GCP resource ID | ||
| "(?:\/([-a-z0-9]+))?" + // capture an optional GCP label for version |
There was a problem hiding this comment.
It is either a number or "latest"
| foo: "bar", | ||
| FIREBASE_SECRET_REF_baz: "quux", | ||
| } as Record<string, string>; | ||
| const { userEnvs: userEnvs, secretRefs: secretRefs } = prepare.partitionUserEnvs(input); |
There was a problem hiding this comment.
FYI: functional.ts already has a partition function. It may be worth just making that support partitioning objects not just arrays.
| default: false, | ||
| public: true, | ||
| }, | ||
| secretEnvParams: { |
There was a problem hiding this comment.
What is the rationale for keeping this experiment guarded? This won't affect any existing behavior because the key was previously disallowed
There was a problem hiding this comment.
Uh at first this was written before API review so I had to guard it in case it was merged before formal approval. I actually do like the idea of guarding it until the params implementation is done though, since anyone who tries to use this without param prompting is in for some undefined and unpleasant behavior.
3 participants
Pulls secrets from the Functions .env files and propagates them into the Functions Build's SecretEnvVars (and from there, into the resolved Backend, and from there, into the JSON uploaded to Cloud Functions/Cloud Run).
Params support not included in this PR, to reduce the size of the review. This is obviously going to be a terrible user experience before params are supported (hence the experiment flag) but this should be enough to test the actual binding behavior.
Quick guide to file change intent:
environments.ts - Adds an experiment flag which by default prevents any changes from being made to the Build. FIREBASE_SECRET_REF_ envs will still be accepted by the parser, but they'll do nothing (and will not appear in process.env)
env.ts - Modifies the key validation logic to allow keys that begin with FIREBASE_SECRET_REF_ even though FIREBASE_ is reserved. Otherwise knows nothing about this feature.
prepare.ts - Partitions the key-value pairs passed from env.ts into the normal entries and the secrets, which have FIREBASE_SECRET_REF_ stripped from the key at this point. If feature flag enabled, calls build.applyEnvSecretOverrides()
build.ts - Implements applyEnvSecretOverrides, which mutates a Build's state to upsert .env-defined secrets into SecretEnvVars before the Build is compiled into a Functions Backend.