Containers are an increasingly popular way to deploy applications because of the improved efficiency and agility they offer.
Container technologies include multiple native security attributes, but they also introduce a number of security challenges that organizations need to consider. The growing popularity of the open source Kubernetes container orchestration platform for deploying and managing containers further adds to the complexity, and potentially opens up additional avenues of risk.
The new deployment paradigm for containers is often referred to as Cloud Native, as containers are particularly well suited for agile, distributed cloud deployment. The widespread use of containers has also led to the emergence of a new category of security technologies, purpose-built for containers;?see eSecurity Planet‘s guide to the top Kubernetes and container security vendors.
At the Kubecon + CloudNativeCon event last month, a trio of executives from container security vendors Aqua Security, NeuVector and Twistlock participated in a panel discussion moderated by eSecurity Planet during Cloud Native Storage Day. The panelists offered their viewpoints and tips on how to secure both storage and applications to help organizations reduce container risks.
Kubernetes can be deployed by organizations on their own without additional tools, but panelists generally agreed that’s not a best practice that should be followed for production deployments for a number of reasons.
Tip #1: Don’t assume Kubernetes is secure by default
Twistlock’s Sonya Koptyev cautions that organizations can not take Kubernetes security for granted, even if it is hosted, managed and running on one of the big cloud providers. In her view, one of the most important things that organizations should do is stay aware and on top of vulnerabilities in the platform.
While managed providers often provide default security controls for their platforms, securing the default platform on its own is not enough, as it’s often individual applications and configurations that can represent risk.
Koptyev also noted that for different industries, security is often tied to compliance with different regulatory requirements. As such, maintaining compliance is something that each individual organization needs to consider, making sure their own applications and use cases are within the required parameters.
“In general, just to stay up to speed, have a tool that plugs into the latest and greatest updates and alerts you in a real-time capacity,” she said.
Tip #2: Kubernetes is not traditional security
Aqua Security’s Roni Osnat advised that traditional security for non-container/Kubernetes systems might not apply for Kubernetes deployments.
While some of the same security concerns, such as malware and abuse of privileges, can occur in cloud-native deployments as well, the control points are different. As such, different tools and capabilities are needed to properly secure Kubernetes deployments.
“We’re talking about a much more dynamic environment,” Osnat said. “If you have persistent storage, that storage itself is maybe managed in a very similar manner to traditional storage, but access to it and how it’s being deployed and used in Kubernetes production environments is very different.”
Tip #3: Have proper controls in place
NeuVector’s Glen Kosaka said that he constantly talks to companies that have put Kubernetes into production without any additional security controls.
Default permissions for Kubernetes might not be appropriate for all types of application deployments and organizations, and it’s important that organizations understand what controls are available. Having control is also tied to having visibility into an application and the deployment environment.
“You know you would never put an application into production without being able to detect both network attacks against it as well as application layer attacks, right?” Kosaka said. “So if you have a business-critical application, why would you launch a bunch of Kubernetes pods where you have no visibility of how the pods are communicating to each other over the network, or what’s actually happening in every pod?”
Tip #4: Validate images
In a traditional operating system environment, organizations have become accustomed to anti-malware scanning prior to installing an application, yet the same approach is not commonplace with containers, according to Twistlock’s Koptyev.
“One of the common things we see is again taking for granted the fact that if there is an image in an open and public repository at a container registry, folks download it and think they can just use it,” she said. “You absolutely must scan and lock things down and also go through and make sure that the image that you pull down is going to actually be doing what you want it to do.”
Among the different threats that have been publicly reported with container images is cryptojacking software. Koptyev added that hackers have become increasingly stealthy at embedding malware, most notably cryptocurrency mining software, inside packages.
Tip #5: Lock down access controls
Whether an organization is running Kubernetes on-premises or in the cloud, NeuVector’s Kosaka said it’s important to lock down and evaluate all the access controls.
Access controls include multiple elements such as service accounts, namespaces and storage volume access. Providing blanket access controls for a Kubernetes cluster in which many different applications run is not a good idea. Rather, Kosaka suggests that organizations review access policies and make sure that only the required access is being granted. Aqua’s Osnat noted that when it comes to storage access, for example, things like storage volume mounts are not secured by default.
“If you don’t do things properly, you’re actually at risk of letting people into your databases through your cloud-native deployment,” Osnat said.
Tip #6: Secure stateful access to non-Kubernetes assets
Containers are often thought off as being stateless — that is they don’t have to run in a persistent manner and can be spun up or turned off as needed. In contrast, data storage, for example, needs to be stateful and persistent in order to maintain the data.
Kubernetes deployments will often connect to stateful (and sometimes non-container) data storage and databases, and there is a need to make sure that those data connections are secured. Koptyev said it’s important that organizations encrypt data storage to help reduce risk. Additionally, organizations should be watching all Kubernetes connections into and out of data storage.
Koptyev suggests that one way to help limit the risk of malicious stateful connections is by first knowing exactly how different container micro services are supposed to be communicating between themselves and with data stores.
“So if you know your normal state of behavior, then you can identify anomalies that happen,” she said.
Tip #7: Take a multi-layered approach to Kubernetes security
Kubernetes and container deployments can be complicated, with myriad elements and components.
Much like with traditional application deployment architectures, there isn’t any one “silver bullet” or approach that can provide uniform security for all scenarios. While the panelists agreed that having security by default is a good idea in general, they also agreed that having defense in depth is also a key best practice for any type of technology deployment.
“Ultimately, security is a multi-layered approach and there’s no one tool that’s going to give you all of the protection for all of the layers,” NeuVector’s Kosaka said. “But you need to think through all of those different layers and then apply the proper tools.”
Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.