Containers and Security: What’s the Effect and Who’s Responsible?
#142: The Intersection of Security with Containerization
Now that containerization and orchestration platforms have upset the proverbial apple cart with respect to traditional concepts such as endpoint security, what are the points in the modern network that get security treatment, and who’s responsible for them? There was talk a few years back about making containerized application developers more responsible for baking security into their images. But in practice — at least in some circles — we’re seeing the job fall to a new breed of site reliability engineers (SRE), whose performance management tasks are now being supplemented with security policy enforcement.
“The folks that are doing SRE at scale are a couple of really hyperscale companies,” said Fintan Ryan, an industry analyst at RedMonk, speaking with TNS publisher Alex Williams for this latest edition of The New Stack Analysts podcast. While the SRE’s purview is typically not security per se, Ryan noted, what they do learn in their current roles about the systems they manage ends up being a security concern.
About the feedback loops that SREs produce within an organization, Ryan said it’s a mistake for folks adopting a Google-like model for the role to assume that SREs’ feedback should be intended solely for developers. “It absolutely isn’t. It’s for everyone in the organization,” he remarked. “And trying to build more and more componentry that allows all of these feedback loops to continuously be running, so people can understand and analyze what’s happening, is an absolutely key thing.”
In the same interview, independent industry analyst Chenxi Wang noted that the latest batch of security startups are taking a very different approach to security policy and frameworks than the traditional, endpoint-centric mindset. “One of the things they’re doing,” said Dr. Wang, “is providing real-time feedback loops as part of their product. So you can make a change and see the change in real time, manifested in the data they’re pulling, and being able to get metrics and measure the effect very effectively and immediately. And those things were typically not present in the traditional security product.”
In This Edition:
3:05: Kubernetes was born from the need to effectively manage services.
5:43: Historically, developers tended not to think about security.
13:19: People’s participation in bug bounties, and the intersection of security with containerization.
26:26: The origin of the site reliability engineer.
30:18: The origin of the “zero-trust” model.
35:23: Whether the API is treated as a product or a service, and how it gets secured in the system.
