Store environment variables in a Secret #86
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #29
Similar to what we've done in the JupyterHub charts, use a Secret for all user-provided environment variables (this includes both the User and
extra_env
provided from the kbatch-proxy configuration).Since the API for specifying environment variables is a Job with EnvVar entries, this is implemented by rewriting the Job during the patch stage, to rewrite every plaintext
value:
EnvVar entry with avalueFrom: secretKeyRef:
, and populating a Secret with those values. It is done last, so there are just no plaintext environment variables in the Job.The Secret is treated much the same as the existing ConfigMap with ownership references, etc.
Inserting the secret is complicated by the current use of
generate_name
(I'll put some more notes in #6), which means the names of all of the Secret, Job, and ConfigMap are not quite known when they are needed.