SBN

Infrastructure in Transition: Securing Containers

Organizations are migrating from virtual server workloads to containers at a frenzied pace, buying into the increasingly popular technology and taking advantage of containers’ many benefits in terms of agility. The application container market is set to explode, according to 451 Research: Annual revenue is expected to increase by 400% over a period of five years, growing from $749 million in 2016 to more than $3.4 billion by 2021.

It’s not hard to see why. Containers are simple to deploy and provide users with greater operational flexibility and compute density, resulting in an optimized build pipeline. Turning to a container orchestration platform, such as Kubernetes, removes an additional layer of operational complexity for even greater ease of deployment and management.

However, a transition in infrastructure is never simple, and along with the advantages come new security challenges. In this post, we’ll discuss some of the risks you should consider before diving headfirst into a container environment, as well as some solutions for mitigating them.

Configuration Errors

Given that containers are a relatively new technology, many organizations have not yet mastered their operations, which would be just fine if they were willing to take their time in transitioning. Many, however, are lured by promises of simplicity and are moving aggressively to deploy containers. This rush to transition infrastructure, coupled with a lack of experience, creates an environment ripe for misconfigurations.

As it currently stands, 73% of organizations have at least one critical cloud security misconfiguration, and that number can only increase with the rushed deployment of technology that is not yet well understood and that lacks a developed body of industry-accepted best practices. Once you add on an orchestration platform like Kubernetes, with its many moving parts, you increase the risk of configuration mistakes to an even greater degree.

We can’t stress enough the importance of taking the time to learn how to configure your containers correctly. Securing your environment proactively through proper configuration is critical — not to mention much easier and less expensive than fixing security issues after they occur.

As Threat Stack’s Pat Cable stated in a recent blog post, “If you don’t have a highly skilled individual on your team, you can find yourself in a situation where it may be easier to completely redeploy than it is to reconfigure, which is obviously going to slow you down.”

Increased Threat Surface

Containers increase compute density by allowing teams to deploy many applications on a single virtual server, but each application runs within its own container. While isolated containers increase agility, the flipside is that they also increase the size of the attack surface as organizations move to deploy large numbers of containers that are each IP addressable.

And just because a container is isolated from your OS doesn’t mean that an attack is any less severe. Cybercriminals often move laterally from within once they’ve compromised a single container, which means one infected container can set off a chain of disastrous events. This is particularly true if your containers are not configured properly from the start.

Lack of Visibility

With certain increases in operational ease come a loss of control over your own environment. Organizations that are used to managing their infrastructure on a virtual server or even managing their own container infrastructure maintain visibility into the hypervisor, server OS, and physical server, but problems may arise once they make the leap into managed Container-as-a-Service, Function-as-a-Service, or Platform-as-a-Service environments.

Looking to capitalize on the growing container market, major players like AWS, Google, and Azure are offering managed container services that promise ever-simpler deployment options. Ease of use, however, comes at the expense of visibility into the underlying Docker and virtual server OS, which are managed by the provider.

While this approach hasn’t yet hit the mainstream in terms of enterprise deployment, the trend could move in the direction of managed service models for containers becoming increasingly popular. When considering your options, it’s important to be aware of the decreased visibility inherent in managed services and to carefully weigh ease of use against potential security tradeoffs.

Securing Containers From the Outset

As is the case with all security measures, building best practices into your container environment in the early stages is easier than trying to integrate them into established workflows down the road. This is why we at Threat Stack recommend establishing advanced SecOps practices from the outset of your infrastructure transition.

A comprehensive cloud security platform like Threat Stack provides insights to help you understand your attack surface and leverage our platform to make sure there are no dark spots. The Threat Stack agent sits inside the virtual server OS, providing visibility into your containers by integrating with the Docker API and playing nicely with Kubernetes. With solutions focused on both the host and on containers, Threat Stack allows you to see deep into hybrid environments.

If you’re in the midst your own infrastructure transition and wondering where to start in terms of security, take our Cloud SecOps Maturity Assessment to see where you stand.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Christopher Ford. Read the original post at: https://www.threatstack.com/blog/infrastructure-in-transition-securing-containers