Two of the most talked-about topics in the world of software development right now are Kubernetes and infrastructure as code (IaC). One of the driving reasons for this is the accelerated digital transformation we are seeing across industries—a survey from McKinsey found that responses to Covid-19 have sped up the adoption of digital technologies by several years. In other words, as companies adopt new modern infrastructures (e.g., Kubernetes), novel security challenges arise that are best addressed by modern processes (e.g., DevSecOps).
According to the most recent CNCF report, Kubernetes is one of the fastest-growing open-source projects of all time. Many of you reading this will either consider migrating existing applications over to Kubernetes or deploying greenfield applications using Kubernetes. Either way, this is the perfect opportunity to also adopt best practices for shift-left security using GitOps and IaC.
The Rise Of Kubernetes
Datadog’s recent container adoption report, published in October, “examined more than 1.5 billion containers run by tens of thousands of … customers to understand how they are scaling and supporting their container environments.” The report concludes that “almost all containers are orchestrated, with Kubernetes used by over half of organizations” and that, despite the popularity of the open-source project, there’s been a 19-point increase in the use of managed Kubernetes services such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) and Azure Kubernetes Service (AKS) compared to 2020.
To address this, we’ve seen a wave of security vendors sharpen their focus on Kubernetes both at build time and runtime. Further, we’ve seen vendors moving from just securing container images to covering IaC security so that vulnerabilities are patched and Kubernetes itself deploys and orchestrates secure workloads. We know that Kubernetes can be a superpower for DevOps that enables engineers to deploy scalable infrastructure that, in the past, would have taken much more time and many more people. At the same time, there are many additional complexities that a distributed system like Kubernetes has under the hood. There are very few single points of failure, and it’s often a series of complex interdependencies that led to an outage or security breach. When something goes wrong, it takes an expert to fix it — unless you have the right tooling and platforms supporting your digital transformation.
The Rise Of Infrastructure As Code
According to a Gartner, Inc. report (subscription required), “By 2023, 60% of organizations will use infrastructure automation tools as part of their DevOps toolchains, improving application deployment efficiency by 25%.” If you’re unfamiliar with IaC tools like AWS CloudFormation or HashiCorp Terraform, they enable the provisioning of cloud resources similar to how developers version source code. The idea is to create a reliable, consistent way to build and deploy infrastructure that can be easily reverted and traced should issues arise. IaC is also how Kubernetes was designed to be managed, making all configurations in a file called YAML files rather than directly to the software itself.
The alternative to adopting IaC is to use a cloud’s user interface or command lines directly to maintain the settings of individual deployment environments, which is not a scalable solution. When, as Gartner predicts, 95% of cloud breaches are due to human error, those direct configurations mean there is no policy checking to ensure secure deployments before launching cloud resources. The other problem is manual changes are much harder to track when a problem arises, and you have to quickly roll the changes back or attribute where they came from. Today, best practices indicate that we should rarely make direct changes to production unless it’s a break-glass SREmergency. If the team needs to make a change, it should be edited in code — not directly in your runtime environment.
IaC can help deliver consistent, stable environments even if the infrastructure itself is highly distributed and dynamic, as is the case with Kubernetes. IaC can be treated like any other code, with a series of automated and manual steps to ensure secure configurations. This bakes in security earlier in the software development life cycle and significantly helps reduce the number of alerts for security teams, reducing the risk of exposed cloud resources. It also creates a highly repeatable and scalable process for building new Kubernetes applications. When developers begin to develop a new application, they can take existing IaC code as a launching point, knowing it is a working framework. If that code has been vetted by security reviews, they can know it’s a secure scaffold for their next project, drastically improving time to market.
We’ve been talking about the great migration to the cloud for years, and hopefully, we can now move on to more automated things—IaC. Up until now, we’ve mostly seen teams building new greenfield applications in the cloud and with IaC. We expect this trend to continue as well as more teams taking brownfield infrastructure that already exists into IaC. This move from manual to automated is the continued post-cloud adoption trend of moving to microservices and containers and now relying more heavily on code and developers.
With the adoption of Kubernetes and IaC, security is set up for DevSecOps and automating security, reducing the friction between developers and security teams. Investing in DevSecOps tools and processes from the start can mean time savings later on—developers spend less time fixing out-of-band issues, and security spends less time combing through audits and monitoring logs and then triaging and managing remediations. IaC tooling will become even more important, popular, and scrutinized as more teams come to depend on it. Setting up the right processes and tools can make security a first-class citizen for developers and set the foundation for a secure future.
This post originally appeared as a Forbes Technology Council post.