Posted by Jeremy Hess
June 6, 2022
Policy-as-code is a relatively new methodology of managing and automating security policies through code. Eran Bibi, co-founder and CPO of Firefly and former R&D Director of Aqua Security, talked with me about how DevOps engineers can harness the power of policy-as-code to validate and secure their cloud deployments.
In this interview, we talk about how policy-as-code takes shift left even further to the left, and we get Eran’s tips on how developers can use open-source frameworks to easily automate policies in the CI. We explore how to find the balance between velocity and security when implanting policy-as-code, particularly at early-stage companies. To wrap up, Eran gives us a sneak peak at Firefly’s latest offering, the open source ValidIaC project.
Watch the episode below
TRANSCRIPT
Jeremy Hess: Welcome to the DevSec for Scale Podcast, the show that makes security a first-class citizen for growing companies. My name is Jeremy Hess, Head of Developer Relations at Akeyless, the Secrets Management SaaS platform. This interview podcast brings security experts and practitioners together to offer practical and actionable ways for small and growing companies to implement security best practices using shift left principles, without interrupting developer lifecycles.
Welcome back everybody. My name is Jeremy Hess with Akeyless, and today my guest is Eran Bibi. He’s co-founder and Chief Product Officer at a fantastic startup called Firefly. They deal with many different things and we’re going talk about that a little bit soon. But Eran, before we get into you and the company and all that, let’s talk a little bit about policy-as-code, which is what this episode is going to be about. So, policy-as-code, it’s a bit of a newer term in the industry and it has these remnants and these ideas of old school policy and things like that. So, can you give us a little understanding about what policy-as-code is all about?
Eran Bibi: Yes of course. So, policy-as-code is one of those trends of doing everything as code. And I think the main advantage of using this new methodology is the power for developers to create policies for themselves, and to use the community to extend the policy surface on their organization. So, it’s a really cool methodology I would say.
Jeremy Hess: Got it. Well, what was it like in terms of looking at policy as an old school term? What was the difference there between what it was and how it’s changed?
Eran Bibi: So, the idea is basically about enforcement and prevention, so you would like to have more control over the stuff that you are deploying on your Kubernetes cluster or cloud workloads. And policy-as-code basically gives you the opportunity to create those gatings in the CI, and to make sure that the configuration that you have in place meets the policy that you decided to put on your organization. It can be stuff that’s related to security. This is the most common use case, but it’s also about having alignment and best practices, and even making sure stuff is built for scale.
Jeremy Hess: Got it, really cool. Alright, so Eran, why don’t you give us a little bit about you, your background, and more about what Firefly is doing today?
Eran Bibi: So, my name is Eran Bibi. I was a DevOps engineer in my previous role. I’ve held a few DevOps positions in the past 10 years, and now I co-founded and lead the product at Firefly, a new startup that basically helps DevOps to get better control over their cloud.
Jeremy Hess: Got it. Alright. Well, can you give us a little bit more detail? What’s Firefly doing in that realm of the cloud and how is it helping customers?
Eran Bibi: Sure, so Firefly is basically a cloud asset management tool, and we scan the cloud and then give you visibility about all the stuff that you have in the cloud. One of the main metrics we provide is what portion of the cloud is managed by infrastructure-as-code, and what is not. And when I say not, this is workloads you’re creating manually using a ClickOps kind of usage or a CLI tool. But in any case, you don’t have any infrastructure-as-code. So, Firefly gives you that visibility, and then gives you the automation to help you to increase that coverage of infrastructure-as-code. So, think about it as the tool that helps you achieve your goals of meeting best practices and industry standards.
Jeremy Hess: Got it. Awesome. So, getting a bit more into policy-as-code. What was the impetus for these changes for policy-as-code? What’s novel about the idea of policy-as-code specifically?
Eran Bibi: So, we have this trend of shifting left, and giving more power to developers to do stuff early in the lifecycle of the software. So policy-as-code is basically the opposite of buying a very expensive kind of security system that gives new enforcement on the runtime. So, policy-as-code gives the power to the developers to use the community manifest and the community powers to put guardrails on the CI, and to make sure nothing is being provisioned into production. And I think Kubernetes has a lot to do with the trend. So, policy-as-code, even if I’m talking more specifically about frameworks that are popular in that domain like OPA, gives you a very simple syntax to create policies on the stuff that you can provision into the Kubernetes cluster.
Jeremy Hess: Yeah, exactly, and that’s where I wanted to take this, to understand a little bit more about OPA. So, first of all, why don’t you give us a little bit more detail about OPA? It’s a very large project and let’s hear a little bit more about that.
Eran Bibi: So, OPA is a framework built by a company called Styra, and I think it’s something like four or five years old, so it’s relatively new. It provides a very simple syntax for creating policies. The syntax is called Rego, and it basically checks against a JSON manifest. So, if you have a workload like in Kubernetes or Terraform for example, you can create, with very few lines of code in a human readable kind of syntax, a gate for stuff.
So, the output of the OPA is basically allow or deny. So, you can create those rules and, let me give you some very concrete examples. You will not allow any workload without a liveness probe to be provisioned into your Kubernetes cluster. So, you basically can create the Rego syntax that works against the manifest of a Kubernetes deployment, and just makes sure you have that block of liveness in your manifest. And if you don’t have it, it will basically provide a deny kind of output and then you can gate it early in the stage of deployment, and make sure you don’t have any deployment running without a liveness probe.
Jeremy Hess: Got it. Okay, so how would a startup or an early-stage company be able to implement a policy-as-code based on the OPA framework?
Eran Bibi: So, it’s very easy, because policy-as-code is a code, and it can be shared in GitHub. You can find tons of projects online that already have built-in kinds of policies that you can use even without writing a line of code. Just cloning those repositories and implementing them on your cluster. So, in Kubernetes’ case, there is a project called Gatekeeper that checks your policy against the running workload and makes sure you don’t have any violation on your runtime. There is also some tooling that you can put even before that in your CI that just scans your manifest. Like a Helm chart or a YAML manifest, and makes sure you don’t have anything that is misconfigured. But I think the real power of policy-as-code is the community.
The fact that you, without writing any line of code, have tons of policies out there and even like a compliance package. You can have PCI compliance, EPA compliance, best practices, well architected, all of that stuff already available for any developers to put on their CI to make sure nothing that is misconfigured will be provisioned to the cloud.
Jeremy Hess: Right, well that’s the power of community. We always love our community members or community friends, and developers helping developers is always a fantastic melding together of minds, so it’s really great. Let’s ask a little more about policy-as-code specifically in terms of the challenges, things that are a little bit more difficult, let’s say. What are the challenges that you see or what’s the biggest challenge, let’s say, of implementing policy-as-code at an early-stage company?
Eran Bibi: So, putting gates, whether it is like denying stuff from being provisioned to the cloud, can be something that can slow you down. So, if an early-stage startup is all about delivering fast value to the customers without having everything perfect, if the DevOps engineer or the one that is in charge of putting those policies is too strict, then it might impact the delivery and the velocity of the development too. So, I think you need to use that wisely and make sure that you maintain velocity, but use policies to prevent something that can be a disaster to the company. So, with great power comes great responsibility.
Jeremy Hess: Yeah.
Eran Bibi: It’s great but you need to make sure again in early startups, to move fast, and then you have the time to fix and align other non-perfect kinds of workloads that you have on the cloud.
Jeremy Hess: Got it. Well, you come from a bit of a larger company that was a startup not too long ago, Aqua. So, you also have that security background. What would you say are some things that you saw at a larger company you were able to implement, but now at a startup it’s a little bit more difficult to implement those specific ideas and tools?
Eran Bibi: So, my experience with Aqua was very similar to what we have right now in Firefly. Because I joined Aqua Security at a very early stage when we were like 20 employees. And again, it was the same dilemma because I was the one in charge of the CI/CD pipeline. I put the tooling in place to make sure the right gating was in place. So, I think if I’m looking specifically at security, the policy was very strict regarding high or critical vulnerabilities, that the CI would basically stop the build if there were such findings, but for less than that we were only about alerting, and not enforcing and stopping the build. Because again, startups need to make sure there is a high velocity of workloads, and developers don’t have to deal all the time with why the CI is stopping the build. Again, as I mentioned, it’s really in terms of finding the right balance.
Jeremy Hess: Absolutely. So, another question I like to ask all my guests when we’re talking about, especially security is, at Firefly do you use your own product to check your own product?
Eran Bibi: Yes of course, we call it drinking our own champagne.
Jeremy Hess: Yeah. Instead of dog food, right? Instead of dog food.
Eran Bibi: Yes, dog food, we found a prettier term for that. So, the dog food protocol in Firefly is about making sure all of our AWS accounts and Kubernetes clusters are integrated with Firefly. And we use that to make sure the cloud is aligned with best practices and everything is codified, meaning described as code. It’s a great kind of experience. We have our own DevOps engineer who uses Firefly like any other customer. And if he finds a defect he opens a defect for the development and it’s a great methodology.
Jeremy Hess: Alright, fantastic. One more question I’d like to also ask is just for our listeners, because of course we’re trying to talk about shift left principles and how to make sure that developers are still able to continue doing their work, with as little stopping and changing as possible. But also make sure that they’re implementing security best practices. What are, let’s say one or two tips you might give generally about how developers can implement security? What are some, in your head, in your eyes, basics that a developer could implement without worrying too much about overhead?
Eran Bibi: So, if shift left was all about putting stuff in the CI, I think right now the trend is even more left than that. So, every plugin that a developer can put in the IDE, whether it’s a DS code or other kind of tooling that gives them the visibility about the status of this code in all of those perspectives. Whether it’s a configuration or even a security on a specific code block. There is great tooling out there that integrates with the IDE. So, this is stuff that I recommend. And I think it’s become a standard kind of approach of having those plugins in the IDE.
Jeremy Hess: Great, that’s a great one. Yeah, I think that developers definitely have that idea. And on top of that, I wanted to ask a little extra here which is not specifically related to this necessarily. I’m going to be doing a meetup with your team on the newest product open-source project that was put out into the world, of ValidIaC. So, maybe as a little preview we can give our listeners, what’s ValidIaC all about?
Eran Bibi: Of course, so we basically created that SaaS offering for developers to have access directly from their browsers to make sure the infrastructure-as-code is aligned with a few verticals. So, we have a security scanner, a linter, and also a cost projection. We use a few of the most popular open-source tools and just combine them into one very nice SaaS-based UI. And of course, it’s open-source, so I encourage everybody to support us with stars and even contribute if you think additional tools can be added to that portal. But I will keep the demo to the meetup.
Jeremy Hess: Yeah, for later absolutely. Fantastic. Alright, so that was a fantastic interview. Eran, I really appreciate your time. Thank you so much. Good luck with Firefly, and hopefully we get to have you on again when Firefly hits their next rounds of funding and beyond. We wish you all the best. So, have a great day and thanks so much.
Eran Bibi: Thank you Jeremy. Thank you for having me.