-
-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use containerd in DIND scenario #150
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. Thanks for the update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: don't we want an article here, like "include a|the crictl binary"
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