In the new Gartner Top 10 FAQs for CTOs on container and Kubernetes infrastructure report, there’s a strategic planning assumption that “by 2029, more than 95% of global organizations will be running containerized applications in production, which is a significant increase from less than 50% in 2023.”
So is that it? Will container and Kubernetes technology finish its adoption curve in 2029?
Not exactly, because while the vast majority organizations will be using containers and K8s to some extent, Gartner also predicts that “by 2029, 35% of all enterprise applications will run in containers, an increase from less than 15% in 2023” – leaving plenty of room for continued adoption as additional applications are refactored or replaced by containerized versions.
Nonetheless, at these numbers, we are in the mainstream now. There are mission-critical applications orchestrated by Kubernetes and its various flavors (managed cloud PaaS, on-prem platform, “vanilla’ open source – for the brave and capable), and containers have become the default way of building and packaging applications. Which begs the question, is there already a “cookbook” for doing this, security and all? And do CTOs currently possess the level and depth of knowledge on the intricacies of securing containerized applications on Kubernetes?
What do CTOs need to know?
From a CTO’s perspective, there are many choices to make when deciding whether to run applications as containerized application on Kubernetes, where and how to structure them, how to connect storage, networking, automation, and many other factors which the report outlines. While containers are relatively standardized these days in terms of how they are built, deployed, and run — Kubernetes is still a very pliable beast, open to many choices (or to too many choices, some would argue.)
For our purposes, I’d like to focus on security aspects. The report succinctly states that:
While there is nothing inherent in the container technology that makes it unsecure, deploying it at scale requires new security models, a mature DevSecOps process, and shared responsibility between developers, platform operations, site reliability engineering (SRE) and security teams.
Let’s break this down.
New security models needed
There are several stark differences between using containers/K8s to older, monolithic ways of running applications. The way in which containers are built, heavily reliant on base images and open source, makes them inherit potential vulnerabilities. The rapid pace in which they are updated and redeployed means you don’t have time to stop and test. The fact that they can be ephemeral and automatically orchestrated means you cannot rely on any permanence of location/IP, or take your time with long sampling intervals (a container might be here one second, gone the next). Additionally, Kubernetes itself can be poorly configured, whether in terms of authentication, how resources are allocated and limited, how it maintains the state of a cluster, and of course networking and storage of application data.
I think by now this is well-understood, at least a high level, by security professionals, CTOs and architects.
Mature DevSecOps process
Nowhere are shift left security and post-deployment runtime security more intertwined than in the world of containers. Proactive, preventive reduction of the attack surface is necessary for runtime security to be effective and not flooded with noise. And while good posture and real-time runtime controls can be effective to prevent attacks and anomalies, it is only by effective remediation of the root causes, whether in the container image, its supply chain, or in Kubernetes YAML files, that we can effect continuous, repeatable improvement in the security and stability of the environment. And it all has to happen at the breakneck speed of DevOps.
Shared Responsibility
Gone are the days when security handled issues “thrown over the wall”, and likewise, there’s an expectation within engineering and DevOps teams that security teams would have realistic expectations about how many vulnerabilities can be remediated, how truly risky they must be to interrupt the flow of code updates, and that a certain level of context must be provided to developers and SREs in order to understand what they need to do to fix things, and avoid repeating them.
This last point also highlights why security is everybody’s business now, and why CTOs must understand the full picture when making design and architecture choices.
At every phase in the adoption of cloud native technology, security has always been the #1 concern, and the #1 enabler when done right. Organizations that fail to address security as part of their blueprint are not just creating security risk, but also creating operational risk which will hinder their ability to execute.
Get the full Gartner report to learn more.
