Cloud Native Security. Chris Binnie

Чтение книги онлайн.

Читать онлайн книгу Cloud Native Security - Chris Binnie страница 15

Cloud Native Security - Chris Binnie

Скачать книгу

with an ls command.

      $ export XDG_RUNTIME_DIR=/home/$USER/rootless $ export PATH=/home/$USER/bin:$PATH $ export DOCKER_HOST=unix:///home/$USER/rootless/docker.sock

      In the previous examples, for ease, $USER is used in place of chris.

      You can also specify a different directory name here if you prefer. Before running the next command, we will need a directory to store our running container content and configuration, so create one now:

      $ mkdir rootless

      Now we can run this command to get rootless mode going, noting that we are using the preferred overlay2 storage driver:

      $ bin/dockerd-rootless.sh --experimental --storage-driver overlay2

      Listing 2.2 shows the end of the output, describing how /home/chris/rootless/docker.sock has connected to Docker Engine in rootless mode.

      Listing 2.2: Docker in Rootless Mode Has Run Successfully

      WARN[2020-08-24T15:51:34.554236269+01:00] Not using native diff for overlay2, this may cause degraded performance for building images: failed to set opaque flag on middle layer: operation not permitted storage-driver=overlay2 INFO[2020-08-24T15:51:34.555462723+01:00] Docker daemon commit=48a66213fe graphdriver(s)=overlay2 version=19.03.12 INFO[2020-08-24T15:51:34.556309674+01:00] Daemon has completed initialization INFO[2020-08-24T15:51:34.602091497+01:00] API listen on /home/chris/rootless/docker.sock

      If you run the following command, you will see the processes running for Docker, as the less privileged user:

      $ ps -ef | grep docker

      Listing 2.3 shows the results.

      Listing 2.3: Rootless Mode Docker Processes Running in the Background

      To start a rootless mode container, we need to point Docker Engine precisely at where the Docker socket file is located. Within a second terminal, we will run the following commands to spawn a rootless Apache container:

      $ systemctl --user start docker $ export XDG_RUNTIME_DIR=/home/chris/rootless; \ export DOCKER_HOST=unix:///home/chris/rootless/docker.sock; \ export PATH=/home/chris/bin:$PATH $ docker run -d -p 8000:80 httpd Unable to find image 'httpd:latest' locally latest: Pulling from library/httpd bf5952930446: Already exists 3d3fecf6569b: Pull complete b5fc3125d912: Pull complete 679d69c01e90: Pull complete 76291586768e: Pull complete Digest: sha256:3cbdff4bc16681541885ccf1524a532afa28d2a6578ab7c2d5154a7abc182379 Status: Downloaded newer image for httpd:latest a8a031f6a3a3827eb255e1d92619519828f0b1cecfadde25f802a064c6258138

      Excellent. That is what success looks like when the Docker runtime downloads an image and spawns a container in rootless mode. Note that if you had not chosen TCP port 8000 but instead a port lower than 1024 (normally TCP port 80 for web servers), then you would have received an error because, as a nonroot user, we can't open a privileged or root port.

      Also, take note that this feature is very new, and the process to getting rootless Docker to work may vary between builds. You have been warned!

      If you run into trouble and need to start again, then carefully as the root user you can try the following command (after trying to execute it as your lower privileged user first) to kill off related processes:

      $ pkill rootlesskit; pkill dockerd; pkill experimental; pkill containerd

      This should stop all the processes so you can start fresh.

      $ docker ps CONTAINER ID IMAGE COMMAND STATUS PORTS a8a031f6a3a3 httpd "httpd-foreground" Up 15 minutes 0.0.0.0:8000->80/tcp

      In the slightly abbreviated output, you can see that Apache's httpd container is running as hoped. To prove that the networking is different with this implementation, we can use this command to check our container's IP address (replacing a8a031f6a3a3 with the name or hash ID of your container):

      $ docker inspect a8a031f6a3a3 | grep IPAddress "IPAddress": "172.17.0.2", "MacAddress": "02:42:ac:11:00:02", "IPAddress": "172.17.0.2",

      We can see that the container is using 172.17.0.2 as its IP address, but now try to connect to the exposed port, TCP port 8000:

      $ nc -v 172.17.0.2 8000

      Nothing happens. The connection does not work using the netcat tool, so we can see that there's definitely a change in the way standard networking is running. According to the documentation cited earlier, this is expected behavior and occurs because “the daemon is namespaced inside RootlessKit's network namespace.” We are not using privileged ports (lower than port 1024), so it is possible to access the container's exposed port; but as you might have guessed, we must do so via the host's network stack. For some potentially helpful context, if you're familiar with Kubernetes, this functionality is called NodePort, where a container directly uses a host port on the host's IP Address so that the container is accessible from outside of the cluster (more can be found at kubernetes.io/docs/concepts/services-networking/service). The following netcat command will work and will not just quietly fail this time:

      $ nc -v localhost 8000 Connection to localhost 8000 port [tcp/*] succeeded!

      And, to prove that is the correct container that responded to our netcat request, we can use the curl command to check that port on our localhost too:

      We have completed the installation of rootless mode using Docker and additionally successfully proven the networking service of a container running as the user chris. The next steps to continue exploring this improvement to container security would be running a number of containers of varying types to check limitations that this mode introduces in a more complex environment.

      For a more mature version of Docker Engine being run without the root user, let's look at another container runtime that can achieve that, too.

      Some industry commentators were surprised when Red Hat applied extra development efforts to a runtime called Podman, as it appeared to come out of the blue (developers.redhat.com/blog/2018/08/29/intro-to-podman).

Скачать книгу