Guest: Guy Eisenkot
Company: Bridgecrew
Show: Let’s Talk

Deploying multiple cloud platforms can be complicated. Other than having all of the right pieces in place to function properly, they can succumb to multi-cloud drift as well. What is multi-cloud drift? And why is it a problem that your business should address right away? Guy Eisenkot, Co-Founder of Bridgecrew, takes on this challenging topic and addresses why it happens.

As per Eisenkot’s assessment, in cloud infrastructure, drifts are the situations where resources that are running are not necessarily using the exact specs that were used when they were originally spun up. This occurs when out-of-band changes are introduced as “part of life.” He references the “break glass scenarios,” when cloud service providers are constantly adding new APIs, new features, and new integrations both externally and internally. Those cause drifts, which, according to Eisenkot, become blind spots in a GitOps workflow. This happens because instead of having a single source of truth, companies are now forced to manage a manifest that has legs and change discrepancies between what’s already running and exists in the cloud.

Drift detection is Bridgecrew’s response to that. The company is trying to empower developers to help them find misconfigurations in Infrastructure as Code (IaC) and help them regain control of those drifts within AWS, Azure, and Google Cloud.

Bridgecrew built its drift detection capability based on an open-source tool they released three months ago. One of their immediate goals is to help the community adopt a unified framework for tracing and tracking infrastructure.

Eisenkot offers up a prediction when he says, “My hope for the near term is that companies that go through this digital transformation utilize some of the variety of tools we have in the ecosystem to move from those legacy setups and onto some of the latest and greatest tech that is generated by both cloud providers and the community to enable them to adopt some of these best practices.”

The conversation then shifts to GitOps and ad-hoc changes. Surprisingly enough, Eisenkot says they’re not seeing as many ad-hoc changes as expected. What’s behind this shift? Eisenkot believes ad-hoc changes simply do not make sense when you’re looking at building robust applications, especially with public clouds and their associated cost operating models. Instead of applying ad-hoc changes, developers need to be employing version control and have automated backups as part of the continuous delivery cycle.

As product builders, Eisenkot says they’re knee-deep in open source. They founded Bridgecrew three years ago and discovered they had to work with open source to get started. He also states that to build a DevSecOps pipeline, open source is a must.

Summary for this interview/discussion was written by Jack Wallen

Here is the rough, full transcript of the show:

Swapnil Bhartiya: Hi, I’m your host Swapnil Bhartiya and welcome to TFiR Newsroom. Palo Alto Networks has announced the addition of multi-cloud drift detection to the Bridgecrew by Prisma Cloud platform. My understanding is that the whole idea is to help teams improve cloud security and manage IT infrastructure more efficiently. But that’s my understanding. To get deeper into it, we have with us Guy Eisenkot, Co-founder of Bridgecrew. Guy, it’s great to have you on the show.

Guy Eisenkot: I’m happy to be here.

Swapnil Bhartiya: Before we get started, and also clarify how good or bad my understanding was. I want to understand from you, because you are a co-founder, post-acquisition what is the focus of Bridgecrew now?

Guy Eisenkot: Our focus hasn’t changed much. We’re absolutely dedicated to helping more and more infrastructure developers around the world just build more secure cloud infrastructure using some of the more accessible tooling out there in the ecosystem. From Amazon web services, all the way to Kubernetes and Terraform. We want to make that as simple as possible by injecting security as part of their development life cycles.

Swapnil Bhartiya: I mean, the kind of trends we’re seeing in this space is that security is no longer an afterthought. It is becoming a priority. A lot of acquisitions are happening. Every week, we see some security focus acquisition. What kind of trends are you seeing, especially in the cloud, cloud natives piece? In terms of security what’s going on because if you look at a lot of reports that come out, there’s still a lot of vulnerabilities. The beauty is that everybody wants security. Everybody wants to talk about security, but the point is what they’re doing about it. Talk about the trends that you’re seeing in the security space.

Guy Eisenkot:I think we’re at the point of mass adoption. I want to iterate themes that you’ve probably heard 1,000 times already. But naturally, COVID has transitioned us to working in a remote environment. We have developers all across the world, powering some of the biggest applications that now run our digital lifestyle.

And that means that if you’re working for Netflix, you need to provision change configurations to withstand the scale of millions and millions of customers. And that’s true probably ever across the world. What that effectively means is that a lot more developers in the past that used to focus on single components of application development, now become much more versatile and touch much more components within that application architecture.

And with that mass adoption comes a second wave. A second wave of challenges naturally, as development and provisioning workflows become prominent, we’re seeing GitOps emerge as the defacto methodology to develop and build enlarged teams. And what that effectively means is that engineering organizations not only have to think of how they grow and build and ship products very fast, but how do they do that in a way that corresponds with the fact that there’s a lot more developer hands on the web? Right.

Swapnil Bhartiya: Right, right, right. Now, let’s switch topics. I’ll resume this topic again, but I want to deal with the elephant in the room, which is this announcement. Let’s talk about multi-cloud drift detection. What exactly it is and how it helps teams.

Guy Eisenkot: In cloud infrastructure, drifts are the situations where resources that are running, are not necessarily using the exact identical specs that they were used to originally get spun up. And what that essentially means is that, when we have developers that are building and provisioning infrastructure, and this becomes a continuous process. The out of band changes that are introduced as part of life. Right.

You get break glass scenarios where Siris are waking up in the middle of the night to ensure apps are running at scale. You have cloud service providers that are constantly adding new APIs, new features, new integrations. These are inherent changes that are happening both internally and externally.

Those cause drifts. Drifts essentially become these blind spots in a GitOps workflow. Instead of having one single source of truth, companies are now forced to manage a manifest that has legs and change discrepancies between what’s already running and what’s existing in the cloud.

Drift detection essentially is our respond to that. We’re trying to empower again, developers. We started with helping them find misconfigurations in infrastructure as code. Now we’re helping them regain control of those drifts by detecting them either in AWS, Azure, Google Cloud. But also, empowering them to respond and to fix them. And correct them back to the original required or defined state, or to overwrite it and persist the change that was introduced as a drift.

Swapnil Bhartiya: What is interesting is that in the case of a company like Bridgecrew, of course, which is part of Palto Alto Newtork  company, most of the driver behind these kind of changes or announcement is alignment with the trends that you’re seeing in that industry. So you do notice that when you do talk about drift that, Hey, what was the lead there and what is running there? Can you talk about what is the driver behind this announcement, or release, or the capability that you’re building there?

Guy Eisenkot: Absolutely. I don’t want to repeat myself, but if we go back to the idea of mass adoption of infrastructure provisioning, and we look at the DevOps ecosystem, we see two interesting things. These ecosystem knows how to adopt technologies very fast. They know how to respond to changes very fast. And they know how to crowdsource problems in a way that both vendors, standalone developers, individual contributors, all can work together to respond to some of these changes that are happening in a very fast-paced ecosystem.

And we’re corresponding with that. We’ve built this drift detection capability actually based on an open source that we released three months ago. And really tried initially to help people regain control of their source controls by identifying infrastructure as code, where it’s provisioned and by who.

And if people use our open source, they actually get the benefit of this drift detection right off the bat. And when you look at this from an industry perspective, we’re trying to help and trying to help the community adopt a unified framework for tracing and tracking infrastructure.

And then also to use our framework to also manage and respond to it over time. But time will tell. Right. We have the bets on this trend as something that engineers and cloud developers are going to actually face for the foreseeable future.

Swapnil Bhartiya: Right. Also, one more thing that is happening as you also alluded to that earlier was, because of COVID, not that people’s strategies change, but a lot of companies, they accelerated their digital transformation or cloud adoption journey. Which also means that as you just said, there are a lot of users who are already very established, but there are new players who are coming in there. And they were really not even aware of all the challenges that come. Cloud looks shiny. It’s good. You just put everything on credit card and you get started. But that’s when the drift also happens. So can you talk about how much challenges are there that you see in that space because of this new users who are coming in?

Guy Eisenkot: Yeah. That’s an excellent point. I used to refer to how we discover and get visibility on cloud infrastructure, much like archeology. What you find is that cloud doesn’t exist for that long. Right. It’s about 10, 12. I think you EC2 just celebrated 15 years. And this is one of the primitive concept of the cloud. Not a lot of time has passed.

But on the other hand, the generational gaps or differences between a first generation application that was formed 10 years ago, 12 years ago, and a microservice-based Kubernetes based application that gets deployed today, are drastically different.

What my prediction or my hope for the near term is that companies that go through this digital transformation utilize some of the variety of tools we have in the ecosystem to move from those legacy setups and onto some of the latest and greatest tech that are generated by both cloud providers and the community to enable them to adopt some of these best practices.

I mean, to be able to use things like infrastructure as code. And to be able to adopt concepts like GitOps in a full DevSecOps life cycle. That’s I think my small hope for the near future.

Swapnil Bhartiya: One more thing I was thinking of as you were answering was that when we do look at GitOps or infrastructure as a code, the basic idea is to lock a few things down so that those changes are not made at that level and everything. But because of either this new users or of course established users, how much adoption are you seeing of these practices? Or are you seeing there is still a mix there? People do want to embrace infrastructure as a code, GitOps practices, but they are still making those ad hoc changes there.

Guy Eisenkot: Surprisingly, we’re not seeing it as much as you would think. I think ad hoc changes are starting to make very little sense when you look at building robust application, especially with public clouds and how they usually build their cost operating model. We see when you want to build the scalable cloud application, you needed to be version control and to have backup that are automated and enabled as part of that continuous delivery cycle.

They need to have logging in place. They need to be safeguarded. I think when you look at all these prerequisites, the idea of not managing this in a way that’s going to be sustainable, just like we manage our react code in our databases.

I think most cloud development teams that we work with understand that it has to be part of that shared notion of a GitOps workflow. I’ve heard are even on this channel, many, many vendors talk through this and thought leaders talk through this. Have you seen that as well?

Swapnil Bhartiya: Yeah. Yeah. And that’s one of the reasons I ask this question also, to get your insight and thoughts on that. Now, one thing that I am also aware of is that Bridgecrew and Palo Alto, you folks also do a lot of open source. I just want to really just hammer that message once again. How important is open source to you folks and what open source project you’re involved with?

Guy Eisenkot: Yeah, look. As product builders, we’re knee deep in open source. We founded this company three years ago. Our previous company was a data analytics company. You just have to work with open source to get started. You have to work with the open source community to build a robust data pipeline and also, a DevSecOps pipeline.

We’ve contributed to some of the best open source in cloud security that we’ve encountered. Projects like Prowler for AWS security, CloudMapper from Duo Labs, Terraformer just recently out of GCP ways. These are projects that we’re helping, I think, continue and strive to make them better and better for the entire DevOps community. Because we do feel like they’re not only pillars for our open core, but they’re also serving a lot of people that don’t necessarily have the big budgets for spending for a big brand product or even for a big internal DevOps team.

As a product naturally, we’re highly invested in open source. We’re, you could say, somewhat of an open court. The product itself is built on a single open-source core checkoff that essentially lets anyone build static code analysis logic. Specifically around infrastructure as code, but not only.

And recently, we’ve used open source also to promote topics and agendas that we feel DevOps as a whole need to progress and strive towards, I mentioned our tagging open source called Yor. Before that we released an open source around IAM and list privileges in AWS, and we have a few more in the pipeline as well.