
.png)
Infrastructure as Code (IaC) offers many benefits but also introduces new security and compliance concerns, along with challenges in controlling cloud budgets.
Join us for a 30-minute lightning talk, where we’ll share practical tips on how env0 addresses these and other risks with a suite of analytics, governance, and drift management tools.
Learn how to make the most of our platform from the best in-house experts!
Watch the video below to learn about:
- The impact of cloud cost overruns and how to control budgets effectively
- Best practices for securing access and enforcing compliance in IaC environments
- How to detect and remediate infrastructure drift before it disrupts operations
and more!
Roni: Welcom, everyone, to our webinar in env0. Today we will be discussing risk, mostly in the context of Infrastructure as Code.
We have Kosta with us, a Senior Sales Engineer on our team, and Yuval, our Director of Product. My name is Roni. I'm the Director of Engineering here at env0.
And we're here to talk about risk in the context of Infrastructure as Code.
Infrastructure as Code, in its own ways, is a way to mitigate risks of traditional ClickOps and other methods of managing infrastructure. Not knowing who changed what and when is a huge problem.
IaC helps solve this by providing approval flows for pull requests, version control, and rollbacks—all of which come out of the box just by using any kind of Infrastructure as Code.
But despite being a major step forward, IaC does have loopholes that need to be addressed with best practices and tools. Without them, you're introducing new risks simply by using IaC.
Yuval, can you share some examples of such risks?
Yuval: Yeah, sure. Thanks, Roni.
As you said, IaC presents a huge opportunity for IT and DevOps teams. But it also introduces some risks:
- Cost management: How do we ensure that costs don’t spiral out of control? Developers and testers may leave resources running over the weekend or provision oversized instances that aren’t needed.
- Access control: How do we make sure unauthorized users aren’t able to modify or delete critical resources, such as those in production environments?
Many organizations implement different access models—allowing more access in staging but restricting production to the DevOps team. But when we open infrastructure up to more users via IaC, these issues need to be managed carefully.
Roni: Great points. We also hear the term Policy as Code thrown around a lot to help mitigate these risks.
Kosta, can you share some scenarios where Policy as Code and enforcement platforms help minimize risk?
Kosta: Yes, certainly. As the saying goes, "With great power comes great responsibility." That's where Policy as Code comes into play.
One common use case is cost controls. Organizations often want to set limits—for example, preventing deployments estimated to cost over $100 unless they receive admin approval. This ensures cost efficiency while maintaining flexibility.
Another example is environment-based restrictions. You might enforce stricter policies in production than in testing environments. This ensures that the right guardrails are in place while still allowing teams to work efficiently.
Roni: The Infrastructure as Code on its own does not guarantee an organization benefits from it simply by using it. I think we've heard some examples right here.
One of the bigger risks out there—and we see this all the time, especially with larger organizations—is that someone, in certain cases, steps in manually. Sometimes they need to make a change by going into the web console of a cloud provider or using an API.
That is what we call drift.
Yuval, let’s talk about this term. Why is it so dreaded?
Yuval: So drift is definitely a dreaded term in the world of IaC, and for a good reason. Drift happens when the actual state of infrastructure no longer matches the desired state defined in IaC. This can occur if someone makes a manual change in the cloud console or if external updates happen outside the IaC pipeline.
Why does this matter?
- Unpredictability: If the cloud infrastructure no longer matches the code, unexpected behaviors can occur when making changes.
- Compliance risks: Policies enforced via IaC can be bypassed with manual changes.
- Operational complexity: Engineers must spend extra time troubleshooting and investigating issues caused by drift.
For many organizations, finding the right tools to detect and fix drift is a top priority.
Roni: Gotcha. Thanks, Yuval. Managing drift is a constant challenge, and one of the biggest questions is trying to understand how drift happens—who made the change and why?
Instead of just talking about it, I thought we’d actually see this in action. This demo will wrap up everything we've talked about and show how env0 helps mitigate exactly these risks.
Kosta, over to you.
Kosta: Thanks, Roni. Let’s dive into the demo.
So that's Cloud Compass.
And I will also point out that with Cloud Compass, being able to read the details of each of the resources, we can pretty much understand what caused the drift.
To demonstrate that, I have this S3 bucket that I deployed some time ago, and I know for a fact that it got drifted.
Under drift detection, I can see that a specific tag—the env0 project ID—was originally assigned, but drift detection was triggered and resulted in a drifted state.
Looking at the plan output, I can see that someone added a new tag that wasn't part of my code, which is why it is now flagged for remediation.
At the same time, another parameter that used to be false is now true.
In env0, we have Drift Cause Analysis, where I can click the Analyze Drift Cause button and drill down into the historical events that led to this drift.
For instance, I see that this bucket was originally created via IaC. The event log confirms it was created in December, and I can also see who created it.
Later on, I notice a ClickOps operation occurred on that bucket. Looking at the logs, I see a put bucket tagging operation was performed, and I can even see exactly who made that change.
This allows me to not only detect when the drift happened but also who made the change and why it happened.
So that's Drift Cause Analysis in env0, helping teams pinpoint and remediate drift efficiently.
Roni: Thanks, Kosta. That was a great walkthrough! To wrap things up, we've covered how:
- Infrastructure as Code helps mitigate risk but also introduces new challenges
- Policy as Code helps enforce security, compliance, and cost controls
- Drift detection and remediation are critical to maintaining infrastructure integrity
We’ve seen how env0 offers tools to help organizations stay compliant, efficient, and in control of their infrastructure. Now, let’s open it up for some Q&A.
Roni: We have a few questions from the audience.
Question: If an organization already experienced cost overruns, how does env0 assist in identifying and fixing those issues?
Yuval: Great question. env0 allows organizations to monitor cloud costs, tag resources, and enforce policies that prevent excessive spending. We provide insights into where overruns occur and allow teams to take corrective actions before costs spiral out of control.
Question: How does env0 prevent unauthorized manual changes to infrastructure?
Kosta: env0’s Policy as Code ensures that only approved deployments are allowed. If someone makes a manual change, drift detection alerts the team, and Drift Cause Analysis helps pinpoint exactly what happened and by whom, enabling fast remediation.
Roni: Those were great questions! If anyone has more, feel free to reach out to us.
Before we wrap up, I’d like to thank everyone for joining us today. A big thank you to Yuval and Kosta for sharing their insights.
If you’d like to learn more, visit env0.com.
Have a great rest of your day!