Improve Security for Docker execution within our make targets

[aepfli]

Description

We're utilizing docker heavily within our make targets. This allows us to reduce the dependencies for our contributors heavily.

Furthermore, we're using the docker images within our GitHub Actions, and therefore we might expose critical information to the execution of those docker images.

Problem

Those docker images could be compromised and configured to share information about our build and environment. (maybe even our secrets - I have not tested this). This could be a security problem for local development and a risk for our execution with Automation pipelines.

Solution

We could limit all our util docker images to not having a network. This way, they can't share the data even if the docker images are compromised. This can be achieved by adding --network none to our executions.

// Shoutout to @tobijdc - thanks for sharing this information :)

[aepfli]

Be aware, some of the utility images we're using need network access (for example HUGO)

[rakshitgondwal]

I can take this up! All I need to do is add the --network none flag in the docker image executions in the Makefile. Some images require network access, so I must take care of that. Is this right?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mowies]

we completely missed this. @rakshitgondwal do you still wanna work on this?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[geoffrey1330]

Hi @thisthat could you please assign this issue to me cc @RealAnna

[thisthat]

Thanks to the work of @geoffrey1330, we discovered the following:

• at compile time, we're downloading dependencies in our docker images. We cannot rely on caching because if we add a new one or bump a dependency, it won't be able to download it
• at runtime, we need to expose the network because we need to communicate with the Kube API

Closing the issue