chore(envbuilder.go): prove the concept of build secret envs

[SasSwart]

This PR proves the concept of build secret environment variables as a safer alternative to #93

[johnstcn]

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.

[SasSwart]

Before building the image using Kaniko, set all the environment variables from above without ENVBUILDER_SECRET prefix.

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?

[johnstcn]

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 kubectl exec) would then potentially end up being able to read the env var.

EDIT: a use case that appears to be common is mounting secrets inside the container with ownership root:root and permission 0400 so that a resulting non-root user inside the container is unable to read the secret.

[SasSwart]

@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.