Unsharing is Caring – User Namespace, Rootless containers and Security

Those who have been working with containers, have long been worried about security aspects associated with underlying containers. One of the vulnerability associated with containers is with running containers as root user. Containers have often required to do some privileged tasks such as mount filesystems, associated with packet route tables on the host networks etc which have historically needed privileged access on the underlying host machine. So this has allowed malicious actors to try to exploit vulnerabilities in containers host.

With rootless containers, we are slowly shifting to overcome this scenario. Rootless containers refers to the ability for an unprivileged user to create, run and otherwise manage containers. This term also includes the variety of tooling around containers that can also be run as an unprivileged user.

Read More »

Parallel Execution with ForEach in PowerShell

The PowerShell’s way of executing parallel instructions has been somewhat complicated till now using Jobs, Runspaces, etc. With PowerShell 7 and above, the team has greatly simplified this requirement with improvement in ForEach-Object cmdlet. You would need two extra parameters: Parallel and Throttlelimit to execute a set of instructions in parallel.

The Parallel parameter specifies the script block that is run in parallel for each input item. The new ThrottleLimit parameter limits the number of script blocks running in parallel at a given time. The default is 5.

Read More »

Going rootless with Docker and Containers

Historically, Docker Engine or Docker has always required root privileges to run. This is because certain features like namespaces or mount points which forms the basis of Docker filesystems have always required elevated privileges. You may have started running docker daemon or dockerd in context of another user, but that user needs to be made part of Docker Group, which was assigned root privileges during installation time. Rootless mode means running the Docker daemon and even containers as an unprivileged user to protect the root user from future attacks on the host system.

Read More »

Going Down the Rabbit Hole of Docker Engine… – dockerd

So you might ask – what does dockerd do? As its turns out, it does quite a lot of thing actually!! Things like networking, logging, docker-swarm, service discovery, DNS implementation, authentication, image management, storage management etc. It also exposes API to listen to requests from docker cli, you know the tool that decides how we interact with docker engine, in our daily lives. Someday these functionalities might be spun off to their own smaller counterparts, but for now these are all the things that dockerd does on a daily basis. Not only this, there are two different versions of docker engine – docker community edition (or docker CE) and docker enterprise edition (or docker EE).

Read More »

Going Down the Rabbit Hole of Docker Engine… – shim

So far we have discussed about runc, containerd in detail and their relative counterparts. We now need to take a look at the component called shim. The shim is integral to the implementation of daemonless containers and separating the low-level container runtimes such as crun or runc from high-level container runtimes such as containerd. As we discussed earlier that containerd uses runc to create new containers. In fact, it forks a new instance of runc for every container it creates. However, once each container is created, the parent runc process exits. This means we can run hundreds of containers without having to run hundreds of runc instances.

Read More »

Going Down the Rabbit Hole of Docker Engine… – containerd

As we discussed in previous posts, that Docker team re-factored, extracted and donated containerd as container runtime to the CNCF in Mar’2017. As of docker engine 1.11, docker engine switch to containerd as default runtime as well and it has been there since. containerd implements downloading images, managing them, and running containers from images. When it needs to run a container it unpacks the image into an OCI runtime bundle and shells out to runc to run it. Also, containerd is platform agnostic, so you can run it on pretty much any OS.

Read More »

Going down the Rabbit Hole of Docker Engine… – runc

As we have mentioned previously, runc was donated to OCI and have been managed separately since then. runc is located at GitHub at https://github.com/opencontainers/runc. It is the de-facto standard low-level container runtime. It is written in Golang based CLI tool for spawning, running and managing containers according to the OCI specification. And its very fast at that. To create a container, runc needs two things – a specification file named config.json and a root filesystem as per OCI specifications, both of these present inside a directory/bundle:

Read More »