-
Notifications
You must be signed in to change notification settings - Fork 28
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
feat(envbuilder.go): add support for build secrets #391
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is somewhat different from what I had in mind, and seems to cross more into the direction of #366
The idea is that we want these secrets to be available during the container build process only. As far as I can tell, this persists them to disk inside Kaniko's working directoryl.
What do you think about the following approach:
- Fetch all environment variables with the prefix
ENVBUILDER_SECRET
and store them in a map or similar - Before building the image using Kaniko, set all the environment variables from above without
ENVBUILDER_SECRET
prefix. - After building the image and just before exec'ing the init command, unset all of the above environment variables.
If the prefix ENVBUILDER_SECRET_
is misleading, we can rename it to something else also.
I did attempt this, but wasn't able to get it to work. each RUN directive starts with a mostly blank environment as far as I can tell. I will revisit this approach though. Perhaps I can get it to work upon closer inspection. Out of interest, why do you prefer the ENV approach as opposed to persisting them to disk? |
I actually don't have a good answer to this apart from 'environment variables are easy and it seems to be the method of least surprise'. However, I can see some folks being wary of passing build-time secrets via environment variable, as someone with access to either the container spec or some 'back-door' into the container (e.g. via EDIT: a use case that appears to be common is mounting secrets inside the container with ownership |
@johnstcn The updated PR should demonstrate a more flexible approach in line with docker standards. The user can now choose whether they want an ENV, or a file. They can also specify where that file should be. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self Review:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general the implementation looks good, had some minor suggestions. Tests need a bit more work though.
@mafredri I've tended to all review notes. Thanks for all the feedback, it was useful! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor nits but otherwise looking good. 👍🏻
This PR adopts support for build secrets from our recent updates to Kaniko to provide a safer alternative to this: #93