Google’s Maya Kaczorowski on Where Responsibility for Container Security Begins and Ends

Twistlock sponsored this post.

A Google Product Manager on Where Your Container Security Begins and Ends

One can reasonably assume container security will undergo many changes in the near term, especially considering the recent widely publicized security breaches (not to mention the ones we do not already know about). But Maya Kaczorowski, a Google product manager, begs to disagree. When it comes to responsibilities organizations share with cloud and tool providers, Kaczorowski, says the model isn’t changing, per se. Instead, “people are becoming less and less worried about the pieces that they don’t have to manage, or the pieces that they used to have to manage — but they are no simpler for whatever reason,” Kaczorowski said.

Shared responsibilities, Google’s approach to container security and recently exposed vulnerabilities and other related themes were the subject of this newest The New Stack Makers podcast with Kaczorowski, recorded at KubeCon + CloudNativeCon in Barcelona in May.

Google has also been playing a bigger role in shared security. More of the secure defaults being built into Kubernetes, for example, “are taking responsibility from the user,” Kaczorowski said. While users are still responsible for applying [Google Kubernetes Engine]  auto upgrades, they can also “enable a feature that lets them be no longer responsible,” Kaczorowski said. “They still have the ability to do it if they want to, but they don’t have to,” Kaczorowski said. “And that’s a huge security benefit.”

Google’s view of container security falls under three categories: infrastructure security, which involves how organizations’ container development environment is secure, Kaczorowski said. This involves network policies, user-identity management, secret management and other similar policies. The second category is what Google calls the “software supply chain,” which covers making sure organizations’ containers are built and deployed securely,” Kaczorowski said. In this way, the second category involves “knowing where your images are coming from scanning them for vulnerabilities and checking that they meet your requirements before you deploy them into your into your environment,” Kaczorowski said. The third category applies to container runtime security and “making sure that your containers are secure to run,” Kaczorowski said.

Still, the shared responsibility model for Google Kubernetes Engine (GKE) and Kubernetes can be a challenge to understand, Kaczorowski said. Google is responsible for the control plane and upgrading organizations’ nodes and the “company’s binaries themselves, but you’re responsible for the worker nodes that you have, and then applying those upgrades,” Kaczorowski said. “I think a lot of other cloud providers have similar models as well here. So, [organizations need to make sure that’s all well-documented and — understood by the user to see what they’re responsible for.”

Google also reacted to the recent Docker exposed vulnerabilities and other supply chain attack in the same way many of its customers did, Kaczorowski said. And So for us, and I’m sure for a lot of our customers, it was, how do we go verify that we’re not using this and if we are, we can go revoke it or redeploy it, or patch it or whatever it happens to be,” Kaczorowski said.

Scanning will continue to play a key role for container security. Available tools should also become further reaching in their scope as well. “Scanning a container vulnerability scanning is particularly interesting, because if you can prevent the thing from ending up in your environment in the first place, that’s better than you having [discovered] it after the fact,” Kaczorowski said.

“So, as long as you can shift those security decisions to the left, and let the developer fix it before it ends up in your environment, it’s better for you from a security point of view,” Kaczorowski said. “So, there’s definitely a lot of interest in scanning and security tools,” such as the ones Twistlock offers, for example.

In this Edition:

1:10: What is the Google view about container security?
5:49: So when you think about container scanning, such as what Twistlock provides, how do you view that segment of the market?
13:26: Is there any learning that came out of the recent Docker Hub attack for you?
17:52: Do you see any open source projects on the horizon that are starting to think about this in the context you’re describing?
24:00: Is there a Google approach to the zero trust model?
28:01: How do you see the open source security space evolving right now?

KubeCon + CloudNativeCon is a sponsor of The New Stack.