Oct 19, 2022
Top IaC Challenges - Extensibility and Integrations
In this video series, we’re looking at the most common challenges with Infrastructure as Code (IaC) adoption and scaling. In this episode, we examine the factors around extensibility and integrations when you’re looking to scale your Infrastructure as Code.
We were joined by Anders Eknert, Developer Advocate at Styra, the creators of Open Policy Agent (OPA). OPA is an open source policy engine: you can feed the engine rules which you then query to make decisions about authorization and access. Anders shared the example of restricting access to medical records not only to doctors, but doctors who have the patient in question under their care. Anders was both a user of OPA and a customer of Styra before joining their team, so he’s well qualified to talk about the challenges that OPA helps to address! Here’s a taste of what’s covered in the video.
As you scale infrastructure as code at your organization, it can become harder to manage rules, authorization, policies, and budgets across multiple teams and machines. Things can get especially complex when your stack is composed of multiple tools and your applications aren’t all written in the same language.
The modern tech stack is definitely diverse… you have all these widely different technologies and they all have their own way of defining rules. The problem with that is how do you know what rules are applied to one particular system, given that your applications might be written in eight different programming languages? How do you audit that—how do you know what’s actually deployed? - Anders
OPA decouples policy decision making from policy enforcement, and can work anywhere that you have rules: authorizations, infrastructure policies, Kubernetes, CI/CD pipelines, and more. You can even set it up so that deployment of infrastructure won’t be allowed if it goes over the budget. OPA provides a unified way to manage policy across your whole stack. This is where the importance of integration and extensibility comes in.
The ideal state is that your developers can fully self-serve the infrastructure and environments they need, while you have peace of mind that guardrails are in place and you have full visibility over what and how deployments are taking place. Being able to manage everything in one place and have a single view of your policy management or even your infrastructure budget management is only possible if all the tools can talk to one another. env0 supports OPA because we believe in giving customers that flexibility and openness over locking you into using any one platform. OPA is not prescriptive, as Anders says, and doesn’t enforce any particular style or way of doing things, so you have full flexibility over how you write policy. This is especially helpful when you’re working with legacy databases for authorization, for example, as these often look different from one org to another.
As you get started with OPA, you may get a lot of ideas about how you can use it, but starting from scratch can be intimidating. Earlier this year Anders launched the Rego Style Guide to help users get to know OPA’s policy language by compiling his own experience and that of the OPA community. Rego has evolved overtime, so it's helpful to get started by reading up on best practices, patterns, and common mistakes to avoid. Users can learn how to create more easily reusable code for their teams.
Watch the full video below for the whole discussion, and learn more about how OPA and env0 work together in our documentation.
