Google unveiled an open source tool that targets container security issues tied to the granting of privileged access to a Docker-based container. Docker containers are by default not granted privileged access to root content, though that does limit their agility.

Analysts have noted that the privileged and root access issues remain a sticking point for securing container deployments.

In a recent container security report, Securosis Analyst and CTO Adrian Lane implored organizations to not “run container processes as root, because that would provide attackers too-easy access to the underlying kernel and a direct path to attack other containers and the Docker engine itself.”

“Organizations need to confirm that access to the Docker client is sufficiently gated through access controls to limit who controls the runtime environment,” Lane noted.

Google's answer to this is the Kaniko tool. It allows for the building of a container image, which is the data basis for a running container. The tool builds the image from a Dockerfile that does not have privileged root access. A Dockerfile is a text document that contains the command lines needed to construct an image.

Kaniko supports the building of an image from a Dockerfile and the ability to push that image to a registry that houses those images for use in other containers.

Google Software Engineer Priya Wadhwa, in a blog post, said removing the privileged requirement allows Kaniko to run in a standard Kubernetes cluster or any environment that can’t have access to privileges or a Docker daemon. A Docker daemon is what builds, runs, and distributes a Docker container.

“Kaniko unpacks the filesystem, executes commands, and snapshots the filesystem completely in user-space within the executor image, which is how it avoids requiring privileged access on your machine,” Wadhwa explained. “The Docker daemon or [command line interface] is not involved.”

The tool differs from similar tools in that it builds as a root user within a container in an unprivileged environment.

Traditional container security models revolve around providing a container with access to only the data it needs to operate. Granting it any more access can open up the possibility that if a single container is compromised it could grant access to the entire container set.

Limiting access to a container is not an issue as most applications running from a container do not need to have access to the broader system. However, organization teams often leave open access to allow for continued work inside of a running container.

Some vendors have looked to bypass the privileged or root issue with Docker containers by using other platforms.

Sylabs, for instance, recently began offering an enterprise product based on the Singularity container platform. The Singularity platform was developed as a way to use container architectures in high-performance computing (HPC) environments and scientific use cases. Those environments typically require more advanced security measures due to the potentially sensitive nature of data used in research and the need to be compatible with on-premises HPC systems.

Sylabs CEO Gregory Kurtzer said that compared with traditional Docker-based container architectures, Singularity includes better security due to the ability to run a container without granting users control of a root-owned daemon process or kernel feature.

Nate Rini, a software engineer at the National Center for Atmospheric Research (NCAR) in Boulder, Colorado, said it has been trialing both Singularity and Docker containers for its HPC environment. However, both have drawn concern over root access.

“We can’t give users Docker on HPC. It gives them root access, and that just can’t happen,” Rini said, though he did note that trusted administrators were using Docker on HPC, but that is still limited.