Container security meets Kubernetes: What IT pros need to know

Source:-techrepublic.com

Docker brought containers into the enterprise; static scanning makes sure they are secure when the images are created. Who watches them when they run?

Docker made it possible to have an exact copy of the core elements of the operating system and the application code in a single, manageable file. BusyBox, the simplest production-ready Docker image, is only 2.1MB. That is small enough to check into version control and small enough to copy around on the network. It’s small enough that every build can be security scanned.

That point-in-time scanning sounds impressive, but it isn’t enough.

SEE: Kubernetes security guide (free PDF) (TechRepublic)

Production containers are computers running in a network that is a cluster, likely Kubernetes. Once they are running, any administrator can secure shell to them and change the configuration or permissions. For that matter, Kubernetes lets every system talk to every other system by default. Auditors tend to care more about the security of the production systems, not some images in version control. That means hardening for HIPPA, PCI, SarBox, and other standards, along with producing the reports the auditors want to see.Rocking your stack
Instead of running a part of the build on a build server, StackRox is a cloud-native security product. It runs inside Kubernetes, with enough privileges to inspect each node in the cluster. It can inspect the nodes for compliance, but also how Kubernetes is configured. Once the policies are in place, an administrator shouldn’t be able to log into a container and change it. StackRox can actually monitor the interaction between containers, creating a YAML file with policy changes, to limit pod-to-pod communications to what they should be. As Michelle McLean, head of community for StackRox, puts it, “Pull rich context from Kubernetes, then push policies into Kubernetes.”

McLean sees this as a tool to bring Security into DevOps. She explains “We bridge security and DevOps. DevOps is trying to learn how to run and configure Kubernetes. Security understands compliance and auditing, but does not understand the infrastructure enough to get that information.” Beyond that, they don’t even speak the language to ask the questions.

SEE: What is Kubernetes? (free PDF) (TechRepublic)

With web and microservices exposed to the open internet, a cloud native, runtime auditor can tell if someone is running a port scan attack, by examining the running processes on the container. Likewise, the tool can tell what processes are running as root.

The product also has the dashboard and visualization tools you’d expect, but that doesn’t solve the audit problem—along with the ability to export reports in .csv format for compliance, by compliance standard.

Instead of forcing yet another dashboard, McLean wants to push data to where the consumers of the data live. For security, that might be splunk; for DevOps it might be PagerDuty or SumoLogic.

Where’s the data?

I also spoke with Jeff Morris, vice president of Product Marketing for Couchbase, about container security. Jeff pointed out that where the data is housed can simplify operations. For example, some cloud service providers, especially Software As a Service (SaaS), store your data on their servers. Morris gave Salesforce as an example, along with many database “as a service” providers. StackRox, like Couchbase, can run entirely in the customer’s virtual or private cloud. Instead of renting CPU hours, Couchbase charges a simple management fee and lets the customer find the most cost-effective storage, all the way down to bare metal.

There are certainly plenty of container security products; StackRox is one. Istio is an open-source project that comes to mind.

Istio’s overlap with Kubernetes security

Istio is another popular open-source program that runs in a Kubernetes cluster and allows users to configure security policies. Like StackRox, Istio can monitor traffic between pods, limit traffic to select interactions, and even create and require authentication policies. Since all the public Kubernetes clouds support it, what’s the use in a commercial tool?

McLean refers to the difference as apples to oranges. In terms of the OSI model, StackRox works at the “network layer,” or level three, monitoring traffic on the network. That is, what nodes are communicating with each other. Istio monitors on the application layer, level seven. It can be aware of security protocols, ports, and the different applications running within a node and how they should connect. It can also encrypt that communication and provide debugging information. According to McLean “Istio isn’t a security product; it is a service mesh configuration product.”

SEE: Kubernetes rollouts: 5 security best practices (TechRepublic)

In my personal experience, Istio can require a great deal of bandwidth, memory, and CPU. Like StackRox, it sits in the same cluster. However, it roughly doubles the amount of messages, as the Istio containers need to receive all of the messages, store them in a database, aggregate them, and display the results as a dashboard. McLean is careful to not overly critique the product, but agrees that it can easily be misconfigured to consume excess resources. It may be easier to let somebody else do it.