Feedback before writing: Clean-out secrets before production

[goldbergyoni]

Context: This is used to share my TOC of a new best practice so I can solicit feedback and ideas before start writing. From my experience, this makes the writing experience much easier and shorter. And fun.

Title: Clean-out secrets before production, avoid build-time args

• TL&DR: Neither build time and run time secrets should be left within Docker images. Build time args for example leave traces. In run-time, a reputable secret management framework should be used. In build time, secrets must be deleted using multi-stage build or [Looking for other simpler technique]
• Otherwise: An access to the image repository will reveal not only code but also precious secrets like the npm keys
• Simple explanation:
• Advanced tip: How to extract build args from image
  Code example: Show how to install packages from private npm repo without leaking secrets

Thoughts? improvement? Help me to make it better

[kevynb]

[Looking for other simpler technique]: We could squash the image, but we lose the ability to cache intermediate layers.

[goldbergyoni]

@kevynb What is squash in this context?

The answer is the new Docker secret feature:
https://www.alexandraulsh.com/2019/02/24/docker-build-secrets-and-npmrc/?fbclid=IwAR0EAr1nr4_QiGzlNQcQKkd9rem19an9atJRO_8-n7oOZXwprToFQ53Y0KQ

[kevynb]

I was thinking about the --squash option (but it's still experimental).
There's also this project https://github.com/jwilder/docker-squash but it's not standard, so it might not even be worth mentioning. Lot of people tend to think that deleting files in a docker build step will actually remove those files, that's one of the thing this project does.

Docker secrets seems to be the way to go, but it's not available by default for now. As the article says:

you’ll first need to enable support for Moby BuildKit

Do we want to recommend things that are not yet included by default? I feel like this adds extra hoops to jump through to get to our solution.
If a beginner wants to try that it might be complicated to tell them that they need to set a specific variable to enable the feature before running their command. Moreover, it's a different method for Windows folks so it could also add confusion.

Maybe we should separate this recommendation in two sections, one with the multi build steps and one titled "Experimental" or something alike with the new Docker secret feature.

[goldbergyoni]

Do we want to recommend things that are not yet included by default?

@kevynb To my understanding it's enabled by default, it was merged from Moby into Docker. Did you read otherwise?

I agree with the bottom line, put it last and mention that it's experimental

[kevynb]

Yeah you’re right indeed. My explanation was confused, I’m talking more about the fact that it’s not enabled by default and that people have to manually enable it by passing an env variable since Buildkit is not the default builder yet. What I’m saying is that It may not be easy for beginners to enable it (it’s not available on windows AFAIK) or to understand what they are doing. That’s why I think it might be useful to have two separate points. Moreover, I had trouble enabling that on a Jenkins host even though it was building on my machine because it was using and old docker version. Anyway, long term I think it’s the best solution :) We don’t need to mark it as experimental as that’s not the case

[kevynb]

Closing as #714 is merged