GitOps: Security, Compliance and Resilience Shift Left
With the emergence of DevSecOps, there has been growing acceptance that security needs to shift left. Developing a complex application and deployment pipeline and then fixing security problems on an ongoing basis is really the only way forward. Delaying releases—in effect, the only alternative—can be a costly business.
But it’s not just about security. There is also its less glamorous cousin, compliance. If you’re operating in multiple territories around the globe, compliance concerns can soon outgrow those of security, for the simple reason that the price of failure can be even higher. For example, the penalties imposed in the EU for contravention of the GDPR laws that govern protection of customer data can be eye-wateringly high—up to 4% of global turnover (not profit), or more than $20 million—whichever is higher.
Even if you don’t buy into the idea of DevSecOps as something truly new—or if you think you already have compliance sewn up—the fact remains that even when it comes to the basics of configuration, you can save yourself a lot of time (and your organization a lot of money) if you can make sure everything is going to work properly from the outset. That’s where policy comes in. Or, more specifically, policy-as-code.
What is Policy-as-Code?
Policy-as-code is a reference to rules that have been coded into the software delivery pipeline—rules that encapsulate and enforce your organization’s policies relating to security, compliance and basic coding/config standards. They can only work as described when the entire pipeline is automated; though, fortunately, thanks to the open source nature of Kubernetes and GitOps components such as Flux, all the necessary tooling is available at a minimal cost.
Of course, there will still be teams who prefer to manage everything manually, regardless of how complex that gets. But the fact remains that, in most cases, secure, compliant, right-the-first-time application delivery simply won’t happen without automated checks in place.
GitOps Makes Everything Easier
Before we get into the details of policy-as-code, let’s back up for a second and examine some of the prerequisites. It pays to be prepared and, in this case, that means getting your delivery pipeline organized before you do anything else.
Containers represent the de facto cloud-native architecture nowadays and, in most scenarios, containers mean Kubernetes. Powerful as Kubernetes is, however, it can quickly become fiendishly complex, especially at scale. Much of this complexity can be mitigated by choosing the correct tooling for your CI/CD pipeline and here, arguably, the most effective model is GitOps—especially if you aspire to the kind of automation necessary to implement policy-as-code.
GitOps exploits the declarative powers of Kubernetes to bring the same level of version control enjoyed by developers to the entire application architecture, including the configuration of the clusters themselves. In other words, it puts everything—configuration information as well as application code—into Git repositories. This turns Git into more than just a source for the code; it becomes a single source of truth for the entire application.
Getting to the Heart of GitOps
At the heart of GitOps lies a software agent that acts as the intermediary between Kubernetes and Git. This agent sits between those two components, constantly monitoring the live application and comparing its real-life state to the code and config in Git that represents its ideal state. The moment it detects any drift, alerts are issued to the platform team.
Flux is the open source agent that sits at the heart of most GitOps implementations. Promoted from the CNCF’s sandbox to incubation status in March 2021 and well on its way to graduation, Flux is gaining traction in the enterprise, whether as part of GitOps pipelines built in-house or delivered via an integration partner. Used by more than 80 organizations, it is deeply integrated into the Kubernetes ecosystem, offering a complete continuous delivery (CD) platform that plays well with tools such as Kustomize, Helm, Kyverno, Prometheus, Minio and more and—thanks to an SDK for building new Flux controllers—this list is only getting longer.
Flux and agents like it are therefore essential to GitOps, which in turn represents a practically unrivaled route to automation of the CI/CD pipeline. But even GitOps will only get you so far. The goal remains a secure, compliant application that works from the moment it goes live. And for that, you need more than just monitoring and alerts. You also need the ability to set guardrails that prevent your entire team—developers and platform operators alike—from doing anything to jeopardize that goal.
The Power of Policy-as-Code
The term ‘GitOps’ was originally coined by Weaveworks founder Alexis Richardson, who explained the need to codify policies this way: “Integrating policy-as-code into the GitOps pipeline allows errors or vulnerabilities to be caught automatically before they make it into production and become a significant cost to the organization. Trusted application delivery—with its declarative approach to compliance and security—will certainly become standard in enterprises’ use of GitOps.”
By automating continuous security and compliance checks, fully automated, trusted deployments are now possible. Policy-as-code ensures that misconfigurations are automatically detected, platform teams are notified and deployments are halted when necessary.
The best way to implement policy-as-code is to adopt a platform that offers not only customizable policies designed around your organization’s needs, but also—to save your team significant time and resources—a library of off-the-shelf policies, ready to deploy from day one. You also need flexibility in terms of how policies are applied. This goes beyond RBAC; your administrators must be free to choose where and how to apply each policy, i.e. which workload, which environment and even which geographical region. And you need to ensure that any violation, in any environment, will send alerts to the right people, at the right time. That means checks must automatically be triggered at all key points in your pipeline including commit, build, deployment and in production (runtime checks).
If You Fail to Prepare, You Prepare to Fail
The ultimate goal of all this is to be able to go faster without breaking things—alongside the other goal, of course, of having everything you make fully operational, secure and compliant from day one. But those two goals are not just contradictory—they are diverging. That’s because the faster you go, the more frequent your deployments and, therefore, the shorter your windows of opportunity to fix security vulnerabilities, compliance failures and old-fashioned configuration errors.
The only answer is automation; yet you can’t have automation without some sort of intelligence baked into the system that can prevent the above problems as they emerge. That intelligence is policy-as-code. In the simplest terms, it is a way of shifting everything left—not just security, but compliance and resilience, too. It is preparation, pure and simple. Consider it a small investment that lays the groundwork for success later on.
Join us for KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain (and virtual) from May 16-20—the first in-person European event in three years!