Use containerd in DIND scenario #150
Open
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
st4rtr3ck
approved these changes
Feb 6, 2024
There was a problem hiding this comment.
I believe the new image could have a slightly higher pixel count to match the old one better.
There was a problem hiding this comment.
I fear the new screen shot could be overwhelming with too much information in too little space on small screens.
| @@ -22,7 +22,7 @@ By the end of the scenario, we will understand and learn the following | |||
|
|
|||
| ### ⚡️ The story | |||
|
|
|||
| Most of the CI/CD and pipeline systems use the underlying host Docker runtime to build containers for you within the pipeline by using something called DIND (docker-in-docker) with a UNIX socket. Here in this scenario, we try to exploit this misconfiguration and gain access to the host system by escaping out of the docker container. | |||
| Most of the CI/CD and pipeline systems use the underlying host container runtime to build containers for you within the pipeline by using something called DIND (docker-in-docker) with a UNIX socket. Here in this scenario, we try to exploit this misconfiguration and gain access to the host system of the worker node by escaping out of the docker container. | |||
There was a problem hiding this comment.
Thanks for the changes here @nmiekley
| @@ -34,7 +34,7 @@ Most of the CI/CD and pipeline systems use the underlying host Docker runtime to | |||
|
|
|||
| ### 🎯 Goal | |||
|
|
|||
| The goal of this scenario is to escape out of the running docker container to the host system where the container is running and able to access and perform actions on the host system. | |||
| The goal of this scenario is to escape out of the running docker container to the host system where the container is running and able to access and perform actions on other container running on the same node. | |||
There was a problem hiding this comment.
nitpick: better pluralize: "other containers"
|
|
||
| :::tip | ||
|
|
||
| We can use multiple methods for communicating with the `docker.sock` UNIX socket. Some of them include [official docker binary](https://download.docker.com/linux/static/stable/), or a simple `curl` program as well. | ||
| We can use multiple methods for communicating with the `containerd.sock` UNIX socket. Some of them include [crictl binary](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md), or a simple `curl` program as well. |
There was a problem hiding this comment.
nitpick: don't we want an article here, like "include a|the crictl binary"
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