Cloud Native Security. Chris Binnie
Чтение книги онлайн.
Читать онлайн книгу Cloud Native Security - Chris Binnie страница 17
Название: Cloud Native Security
Автор: Chris Binnie
Издательство: John Wiley & Sons Limited
Жанр: Зарубежная компьютерная литература
isbn: 9781119782247
isbn:
Just as we did before with Docker in rootless mode, let's see how our networking is set up. We will open up another terminal (as the chris user) and try this command:
$ podman ps CONTAINER ID IMAGE COMMAND CREATED e09883662c2b docker.io/library/httpd:latest httpd-foreground
The abbreviated output proves we have httpd running as hoped. It is worth noting that other standard users will not have visibility of Podman container processes, but the user chris certainly does. We can see the container is definitely running, and not as the root user:
$ ps -ef | grep podman
The abbreviated output from that command shows, among other entries:
chris 6069 6035 podman run -it -p 8000:80 httpd:latest
Do we need to access the container via the host's network, as we did with Docker? We can test with this command:
$ curl localhost 8000 <html><body><h1>It works!</h1></body></html>
The answer is yes, we've exposed a nonprivileged port (TCP port 8000) and can access the container via the localhost. If you get stuck, check firewalling rules or other container runtimes that are still installed.
One difference between Docker and Podman in rootless mode is that Podman does not allocate an IP address by default. Using the previous podman ps command, we can see our container's hash ID is e09883662c2b. The next command should offer us internal IP addresses, but not in Podman containers:
$ podman inspect e098 | grep IP "IPAddress": "", "IPPrefixLen": 0, "IPv6Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "LinkLocalIPv6Address": "", "LinkLocalIPv6PrefixLen": 0,
The top line in the output demonstrates that an IP address doesn't appear to be allocated, even though from a container's perspective an IP address is actually allocated via slirp4netns (the component that provides userspace networking functionality that was installed earlier). The container can apparently only communicate over the network with the host and beyond (and not other containers). There is more information at github.com/rootless-containers/slirp4netns. Thanks to the fact that Podman provides no default networking bridge, this is a limitation when using slirp4netns, which is part and parcel or using rootless mode.
If you need to run the ping command from a rootless container for any reason, you might need to tweak the kernel. You can temporarily adjust the tunable kernel setting with this syntax:
$ sysctl -w "net.ipv4.ping_group_range=0 2000000"
To make sure this setting survives reboots, you should add the following command to copy it to a file:
$ echo "net.ipv4.ping_group_range=0 2000000" >> /etc/sysctl.conf
The documentation encourages you to delve into the /usr/share/containers directory. As a low-privileged user, you should be able to read the files but not necessarily edit them, as these are for the sysadmin to edit. The files are as follows:
containers.conf seccomp.json
If you look inside the directory /etc/containers, then you can apparently override the settings in the previous directory. The file listing looks like this:
containers.conf policy.json registries.conf registries.d/ storage.conf
Note that Podman reads these configuration files in this order, with the last overriding the previous file's settings potentially:
/usr/share/containers/containers.conf /etc/containers/containers.conf $HOME/.config/containers/containers.conf
The containers.conf file contains a number of user-tunable settings. You can configure cgroups (control groups) and resource quotas such as RAM and CPU, and you can also define which kernel capabilities are included. In Listing 2.5 we can see many default capabilities have been commented out, which means they are not in use but are instead replaced by Podman's corresponding default settings.
Listing 2.5: Some Additional Kernel Capabilities That Can Be Uncommented for Containers to Use
# List of default capabilities for containers. # If it is empty or commented out, # the default capabilities defined in the container engine will # be added. # # default_capabilities = [ # "AUDIT_WRITE", # "CHOWN", # "DAC_OVERRIDE", # "FOWNER", # "FSETID", # "KILL", # "MKNOD", # "NET_BIND_SERVICE", # "NET_RAW", # "SETGID", # "SETPCAP", # "SETUID", # "SYS_CHROOT", # ]
The storage.conf file is a comprehensive way of tweaking your rootless container storage options. You can remap UIDs and GIDs if required so they appear differently inside and outside your containers to suit your volume mounting needs.
There are also settings for the devicemapper logging levels, which can help debug storage driver issues if required.
Inside the registries.conf file it is also possible to set up your image registry settings. In that file you can see the following:
[registries.search] registries = ['docker.io', 'quay.io']
And, in the registries.d/ directory you can configure the settings required to access those container image registries with authentication, for example.
Summary
In this chapter, we have proven that running containers without relying on the exposure of the root user is thankfully now no longer a distant reality when running containerized workloads.
Our first container runtime, Docker Engine, needs some more fine-tuning to get rootless mode working but did successfully launch a fully functional container, without needing the root user. The second runtime, Podman, not only does not need to run around the clock as a daemon but additionally took little effort, using Ubuntu 20.04, to install. Its configuration also looks like a logical process in addition. Remember that not only is Podman capable of running with less privileges, but it is also a highly versatile, lightweight, and daemonless container runtime that can be used in a number of scenarios as the root user too.
Watch this space carefully. Although the nascent rootless innovations still need a little more work, rootless Podman is growing increasingly mature. Thanks to Red Hat's reach within enterprise environments, it is used extensively in OpenShift v4.0 platforms and is indeed battle-hardened as a production container runtime.
CHAPTER 3 Container Runtime Protection
In previous chapters, we looked at the need to get the permissions correctly configured to protect other containers running on a host and indeed the host itself. In Chapter 6, “Container Image CVEs,” we will also look at protecting against common vulnerabilities and exploits (CVEs) to СКАЧАТЬ