Virtualization Technology News and Information
VMblog Expert Interview: Bridgecrew Talks GitOps Movement and Its Multi-Cloud Drift Detection

interview bridgecrew eisenkot 

The team at Bridgecrew has been on a roll in 2021, bridging the gap between cloud security and developers.  To continue on that trend, the company has announced a new feature, Multi-Cloud Drift Detection.  To find out more about that new feature, as well as what's happening in the GitOps movement, VMblog spoke with Guy Eisenkot, the Co-Founder of Bridgecrew.

VMblog:  I want to ask you to start -- what are you seeing with the GitOps movement?  Are people actually adopting it or is it reserved for highly advanced companies?

Guy Eisenkot:  GitOps is somewhat of a buzzword that borrows ideas from methodologies that most companies have been doing for years such as DevOps and Agile. GitOps takes those methodologies and applies them to managing cloud infrastructure in a more repeatable, scalable, and consistent way.

And like everything, there's a spectrum of adoption. Most companies are probably in the early stage of that spectrum, but it's hard to gauge because of differing ideas as to what exactly GitOps is. Simply put, I define GitOps as using three things-infrastructure as code, version control, and continuous integration and deployment-to manage infrastructure.

The extent to which you're following GitOps varies depending on your level of automation around your integration and deployment pipelines. But at the most rudimentary level, if you're managing Kubernetes clusters purely with yaml and git, and not manually exec'ing into a pod or using kubectl edit, you're following GitOps. If you're using infrastructure as code and git, you're using GitOps.

Kubernetes usage is pretty widespread, but adoption of IaC frameworks like Terraform is still early. Why is that? Part of it is because Terraform is relatively new and complex. Part if is that Kubernetes was born with IaC as the default operating model. We've had infrastructure and cloud for years before IaC started to take over as a way to configure everything. It takes time and resources to adopt something new and there is always a challenge to break old habits.

I think the biggest single reason that bigger companies may shy away from adopting GitOps is the additional complexity it adds in terms of repositories necessary to support large environments and the challenges that come along with that-access and provisioning, secrets management, siloes between teams, etc.

VMblog:  Can you explain to our audience what some of the key advantages are to adopting GitOps?

Eisenkot:  Let me start by comparing it with the old way of doing things. You used to go into a cloud console or CLI and go through the steps to provision each service. That's not scalable. Then try to make a multi-service update. Now you have to go back into each section to make that update.

Because GitOps has infrastructure built in code and version controlled, infrastructure is:

  • Faster and more reliable to provision
  • Easier to understand and therefore improve
  • Easier to collaborate around
  • Easier to replicate for disaster recovery and new projects

We of course take a special interest in the benefits regarding security. Leveraging GitOps allows for more proactive security controls and guardrails before anything is deployed. IaC's machine readability allows for straightforward scanning, and passing that code through predictable code reviews and pipelines allows for collaborative and transparent security policy enforcement when you have large, dispersed teams.

VMblog:  No team does it perfectly, right?  That's the idea behind your new feature announcement, Multi-Cloud Drift Detection.  Can you tell us more about it?


Eisenkot:  Even the most advanced companies will have moments where breaking GitOps (aka making a change not in code) is inevitable. Sometimes it's removing a security control when an application goes down. Other times, someone might identify a bug in the cloud and fixes it right there.

That's not a bad thing temporarily - you made a fix! The problem is when you go back to the infrastructure as code template, they're now out of date. You can rely on them to be the source of truth. If you go to see who made a change, it won't be in the code. If you talk to a teammate about how to improve your infrastructure, you can't do that in the code. If you go to use that code as a starting point for your next project, it's not nearly as useful. You get the idea.

Drift detection let's you know when your cloud and code look different. Our Drift Detection feature spots those differences and shows you a comparison in code next to code. This allows you to decide if it's a change you want to keep or if you prefer the IaC version. If you want to keep the change, simply run our "drift fix" and the code is updated. And we do this across AWS, Azure and GCP.

One other thing to note - drift detection with drift fix makes it easy to make fixes in the cloud and apply it back to your code retroactively. However, we still recommend doing it right the first time in code with IaC scanning. It's still easier to do it right the first time, this is a second parachute in the bag type of thing.

VMblog:  How does it actually work?  What's going on behind the scenes that makes it possible to detect drift and notify users?

Eisenkot:  Bridgecrew Drift Detection is rooted in the simple problem our customers have-being alerted when their infrastructure sources-infrastructure as code hosted in VCS repositories and resources deployed in cloud environments-are out of sync.

Unfortunately, this simple problem didn't have a simple solution. It turns out there's no industry standard across cloud providers and infrastructure as code frameworks to tie cloud resources back to the IaC that defined them in a common language.

That's in part why we created Yor. In addition to adding other valuable metadata in the form of tags in IaC resource blocks, Yor is an open source tool that makes code to cloud traceability simple and infallible.

Then we add our ability to convert cloud configuration into code. AWS, for example, can provide you JSON or YAML outputs of your cloud configuration, but if you're comparing that to your Terraform code written in HCL, it doesn't do you any good. We convert that cloud configuration output into HCL so you can compare apples to apples.


Bridgecrew Drift Detection builds on top of Yor's traceability to link code resource blocks to cloud resources. Comparing the two code representations let's us detect when runtime resources are out of sync from IaC resulting in drift. This capability, when used in tandem with Bridgecrew's Slack notifications make it easy to continuously be alerted of new instances of cloud drift. All Bridgecrew customers (or those in a free, 14-day trial) need to detect ongoing drift is integrated cloud accounts and VCS repositories containing the corresponding code.

When cloud drift is detected, there are two potential reasons for it. The drift may be a temporary or accidental change that needs to be quickly reverted, or it may be a permanent or intentional change that needs to be codified. In the former case, Bridgecrew and Yor tags make it easy to identify the IaC in question to redeploy the right configuration. In the latter case, the Bridgecrew platform allows users to instantly "Fix Drift" and open a pull/merge request to implement the correct configuration in code.


Published Tuesday, August 31, 2021 7:30 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<August 2021>