Container security starts with Kubernetes


The rise of container technology is undeniable, and it’s not hard to see why. By offering greater DevOps flexibility as well as an optimized build/deployment pipeline, container technology is allowing companies and their development teams to build faster, deploy software more efficiently and operate at an unprecedented scale. Gartner estimates that 50 per cent of companies will leverage container technology by 2020, up from roughly 20 per cent in 2017, and this momentum is sure to continue to rapidly increase.

In response to widespread container adoption, many development teams are embracing Kubernetes. Kubernetes the most popular, open-source system for automating the deployment, scaling and management of containerized applications. The technology popular for good reason, as it allows for continuous integration and delivery, in addition to handling the network, service discovery and storage of multi-container clusters at scale. Better yet, Kubernetes can do all of this in multi-cloud environments.

Essential Kubernetes security considerations

While container technology and related orchestration tools like Kubernetes are undoubtedly valuable and worthy of embracing with enthusiasm, some development teams are jumping on the bandwagon too soon and too quickly, allowing their “Kubernetes FOMO” to blind them to the critical security risks implementing these technologies can introduce.

Below are two key infrastructure security considerations to keep in mind before deploying containers with Kubernetes.

1. Misconfigurations can leave private information exposed.

Since containers are relatively new and require a comprehensive understanding of the technology, the risk of misconfigurations due to inexperience can be extremely high. For example, while third-party tools such as Docker secrets and HashiCorp Vault can encrypt private information, many Kubernetes users rely on Kubernetes’ own mechanism to encrypt private data they don’t want hardcoded, such as service passwords and API keys. This is perfectly fine, however if there are any configuration errors, private information could be exposed. Make sure to review Kubernetes’ detailed documentation ahead of deployment to prevent such a dangerous vulnerability.

Another common configuration error when deploying Kubernetes is allowing an authentication token to automatically provide access to the Kubernetes API (it’s actually a default setting). Configuring role-based access controls (RBAC) can help here, however, if the token has cluster admin rights, remember that an attacker could easily escalate these privileges to take control over an entire cluster.

2. Blast radiuses can quickly increase.

The blast radius of Kubernetes-controlled deployments refers to how far an attacker can have negative effects from the initial point of compromise. It’s crucial to recognize that blast radiuses can quickly increase once a container is compromised if an attacker is able to escalate their privileges to take control of other containers within a cluster.

Equally important is recognizing the fact that attackers have identified end user-induced security gaps within Kubernetes’ backend database (etc) by searching on web crawlers like Shodan. In fact, Kubernetes’ own security documentation states, “Write access to the etcd backend for the API is equivalent to gaining root on the entire cluster and read access can be used to escalate fairly quickly.”

To help limit the impact of compromised containers, take advantage of Kubernetes’ built-in container access controls and leverage their isolation mechanisms, such as namespaces and network segmentation. Also, consider reducing the number of containers that have permission to run in privileged mode, since compromised privileged containers can cause even more damage than compromised normal containers.

Proactive infrastructure security planning is key

As with most emerging and complex technologies, the best way to prevent chronic security vulnerabilities in container technology is to build security into your deployment from the onset and work to continuously reinforce it. In the rapid deployment world of containers, a simple configuration mistake can quickly be proliferated across your deployment as your environment scales!

Remediating a data breach after it occurs will always be more complex, costly, time-consuming and damaging than securing an environment proactively through proper configuration. Furthermore, by integrating a security program into deployment operations from day 1, will help to ensure company infrastructure won’t be left perilously exposed.

Before deploying containers with Kubernetes, read the Kubernetes security documentation closely and ensure the entire development team fully understands the technology to prevent any misconfigurations. Incorporate Security Operations practices through proactive infrastructure monitoring to protect serverless environments, and work preventatively and continuously to limit the impact of any compromised containers. In doing so, companies and their development teams can confidently reap the benefits of container technology, without running the expensive risk of incurring a data breach.

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x