Use containerd in DIND scenario #150
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for the amazing work @nmiekley @st4rtr3ck 🙏 |
This was referenced Jun 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
use containerd instead of docker in DIND scenario
Motivation
Moved from Discussion to Pull Request:
The original idea of the scenario is that docker is running on the worker nodes and managing the containers for kubernetes. However, with kubernetes deprecation for docker shim this is no longer the case. Now, either containerd or cri-o is used as container runtime for kubernetes.
The same exploit can still be done, we only have to use the containerd. I tested it on AWS EKS and kind, but of course for a cluster with cri-o a different socket needs to be mounted.
I am not sure how to name the updated scenario so I am open to suggestion.
Btw, the current setup also has a funny effect in KIND: here the docker daemon you gain control over is the one on your machine running the kind node. You can still get control of the KIND node and the containerd inside, but that is not really a production relevant scenario. This pull request also avoids the special treatment of kind and you now correctly gain control of the daemon in the cluster nodes.
This would probably solve this: #127