containers container native container security root access

Root Access Creates More Container Security Problems than it Solves

By /

Containers have become a mainstream staple of application development these days, and—as container adoption hits critical mass—container security has become a growing concern. There are a number of approaches to container security in the market right now, but many of them rely on having root access to the host. The problem with container security that requires root access is that it has significant limitations and exposes the environment to additional, unnecessary risks.

Root Access for Container Security

Two of the prevalent approaches to container security are a kernel plugin and privileged security containers. Both of these container security solutions depend on root access to have the visibility to monitor for security concerns and the capability to do anything about it.

A kernel plugin loads a kernel module on the underlying host to monitor calls to containers. The plugin runs in the kernel—which requires access to the host and grants root access by default.

Privileged security containers require root access to provide visibility into all other containers running on the host. Other containers are redirected through the privileged security container so it can monitor container activity.

The Problem with Root Access

Both of these container security approaches—kernel plugins and privileged security containers—do provide a level of security for the container environment. The problem is that they each create new issues of their own as well, and—ultimately—limit the scalability and portability of your containers.

Layered Insight

Both kernel plugins and privileged security containers are dependent on the underlying host in some way. The need for root access means that neither of these approaches will work in a CaaS (containers-as-a-service) environment like AWS Fargate, or in serverless computing offerings. One of the primary benefits of containers is that they are ostensibly platform-agnostic and able to move seamlessly between different hardware and software environments, and serverless computing and CaaS are quickly emerging as the new standard for container environments, so that is a significant limitation.

Privileged security containers also have a few additional caveats. For starters, they are only capable of monitoring 10-15 other containers on the host. The most serious issue, however, is that because privileged security containers have root access, they themselves become a primary target for attackers.

A Container Native Approach

The best way to implement the security you need without trading away some of the primary benefits of using containers in the first place is to embed security within the container itself. A container native approach provides complete visibility and control of containerized applications throughout the entire lifecycle without the need for root access.

Because the security is part of the container, you get insight into what is going on in the container, accurate vulnerability assessment, and compliance validation. A container native approach also allows you to have automated anomaly detection, and enforcement of container policies and behavior.

The lack of root access means that the container native approach delivers on the promise of portability and scalability for your containers as well. There is no dependency on the host or underlying infrastructure, and the embedded protection and enforcement enables you to scale as much as necessary.

As container adoption grows and organizations deploy more and more containers, security is a primary concern. Avoid container security solutions that require root access, and focus on an approach to container security that gives you the protection you need while still delivering on the promise and benefits of containers.

Latest posts by Tony Bradley (see all)

Related Posts

Comments are closed.

Scroll to Top