-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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