Taking a Comprehensive Approach to Container Security in 2018
In late 2016 we enlisted the help of security analysts and thought leaders Securosis to perform an in-depth best practices analysis of what companies should do to build a security program around containers. In the 14 months that passed, many things have evolved in the container (and now, cloud-native) ecosystem. So much so that we felt it's time for a refresh of that analysis, and a new webinar on securing containers in the enterprise. Let's take a look at some of the key points we'll cover.
What Has Changed?
During 2017 the container ecosystem has both diversified and matured, and there are now many more tools that enterprises can use to deploy cloud-native applications. Kubernetes has emerged as the leading standard for orchestration (though is still very much a moving target). Platform providers like Red Hat OpenShift have made it easier for enterprise to control deployments, and cloud providers have improved their offerings while also embarking on new formats such as AWS Fargate and Azure Container Instances.
Organizations have also evolved in how they view containers and how they manage the application lifecycle around them, including security. Whereas previously most deployments were isolated pockets of greenfield applications developed using Docker, nowadays cloud teams and application teams are taking broader holistic approach, examining how they can transform their entire application stack into an agile, scalable machine. This also calls for a holistic look at security.
Developer <> Security team
One of the challenges is still the disconnect between DevOps and security priorities. DevOps’ main mission is to get the product out as fast as possible with as little maintenance as possible, and security is a necessary evil. Security teams on the other hand, lack visibility and have difficulty validating containers leading up to and during production.
In enterprise environments, goodwill on both sides can only go so far. Security must fulfill stringent requirements for compliance, reporting and threat mitigation. “Best effort” is often not enough, and full visibility is required.
Threat Landscape for Containerized Applications
Potential attack vectors that threaten containerized applications can be grouped into several types:
1. Threats to the Build Environment
The build environment should be on the top of your security checklist, primarily because developers can’t be expected to all be security experts. The developer has an interest in building the product as quickly as possible, which means that they do not have time to test data management or masked data.
Furthermore, bugs in the source code, alterations to automated build controllers, and insecure open-source libraries, among other factors, can introduce serious vulnerabilities into the system. Failure to thoroughly audit the entire build environment process can lead to bigger problems that will be more difficult to solve down the road.
2. Vulnerabilities in Container Images
Especially when using open source base images, vulnerabilities may be introduced into containers. These vulnerabilities may arise by failing to update the machine with newer patched versions, improper configuration and can be exacerbated by cyber attackers actively looking to take advantage of these vulnerabilities.
3. Container Runtime Security
Does the container include tools like ssh, which allows content to be easily changed? Is the operational security and underlying container host protected via appropriate mapping access to OS and host resources? Have hardened security features been used and how have they interacted with the container? The truth is most people in security operations won’t know the answers to any of these questions. The operations team will most likely not even know what is in the container, which means everyone needs to be brought up to speed.
4. Platform Security Issues
The goal here is to block all but subset of resources that the container must access in order to run the application, i.e. rigorous application of least privileges. Why? What could go wrong if that’s not done? If the container attacks the underlying OS or the container engine itself, the impact would be significant. Such an attacker could own the host, and from there easily spread to other systems.
5. Secrets Management
This has emerged as particular pain point for DevOps teams. As containers require access to keys and passwords to function, the challenge is how to avoid exposing those secrets to other containers, unauthorized users, or over the network. While not a challenge unique to containers at the enterprise level, it presents unique requirements when it comes to containers due to their orchestration and ephemeral nature.
6. Orchestrator Security Issues
Orchestrators are the main management interface to run containers in production. As such, they are the front door to application runtime environments, and must be properly secured. Unfortunately, recent breaches such as the one at Tesla have shown this isn't always the case, and not due to lack of availability of tools or best practices - but rather due to negligence and ignorance.
Container Security is Here to Stay
Although container technology and security practices around are still maturing, a lot of the tools needed to deliver and manage container security are available and already proven in the field. DevOps and security do not have to battle it out. With the right procedures, and by assembling a container security program, organizations can continue to enjoy the significant advantages of agile, scalable deployment of cloud-native applications, while compliance and security are adhered to as well.
For an in-depth look into these challenges and how they can be tackled through a comprehensive approach, join us for our live webinar with Adrian Lane from Securosis.