The Art of Modern Ops: Authorize better with OPA - security policy as code

July 22, 2021

Podcast

security

Policy as code Shifts Security Left

How Trusted Delivery Unifies Security Practices Like IAM, RBAC, & ABAC

No More Manual Reviews — Policy as Code to the Rescue

The Art of Modern Ops is a regular podcast on modernizing cloud infrastructure from Cornelia Davis, Weaveworks CTO and author of the book Cloud Native Patterns. In the latest episode, Cornelia interviews Gareth Rushgrove, VP of Product at Snyk. Together, they talk Kubernetes, GitOps and policy – focusing on Open Policy Agent (OPA) a recently graduated project in the CNCF.

With a background including stints at Docker and Puppet as well as the UK Government Digital Service, Gareth specializes in application development security tools, including OPA. As Gareth explains in this episode, OPA is important because it provides an essential function: the ability to define and enforce a single set of policies and manage them all through a single interface, rather than using different languages, models, and APIs for different tools, across your organization.

Move to the left

Centralizing policy management is consistent with the established DevOps goal of shifting everything to the left in the software development life cycle. Because in this context, policy is primarily about defining what your engineers are allowed to do and what they are not. DevOps aims to bring strategic decisions like this closer to the beginning of the timeline, rather than have a change control department getting involved later on, to say, “no, I’m afraid you can’t do that”.

GitOps assists with this leftward shift by holding everything in a Git repository – including policy information. So one of the first questions Cornelia puts to Gareth on the podcast concerns whether holding information in a repository like this is sufficient – or are things more complicated than that?

Life is never simple

The answer, of course, is that life is never that simple – and that is often down to human issues, rather than technology. Specifically, it concerns the importance of context and the question of who the user is. The ultimate aim of defining policies earlier in the SDLC has to be to improve clarity surrounding who can do what. But it should also go further, eliminating dysfunction in the organization. For example, if the application developers fundamentally disagree with the limits placed on them by the security team, they may deliberately override those controls in their code. That, as Gareth says, is an example of a broken organization. But it’s also real life, which is why it’s so important to centralize policy management – even if you’re running the full GitOps model, with everything held in version control and alerts being fired off to your platform team whenever the production app drifts.

I think it's always contextual. And it's always about the who. I think in some cases you might have a really strongly, assured pipeline, you absolutely decide that you have no other access to your cluster and you're a small team and you're making prioritization decisions. At that point you might accept the risk that some of the things can go wrong.

OPA helps you get organized

Policy, it seems, is not just a technical consideration. It can also be a tool for organizing people; for helping them to work together more effectively and for eliminating the human conflicts that can prove costly.

That’s why shifting policy decisions to the left with a tool like OPA can be so important, even if you already manage your platform via GitOps. It means you can have one set of policies for everyone and that crucially, those policies are clear to everyone at the outset. GitOps helps centralise and automate many things. But it becomes even more powerful when used in combination with complementary cloud-native tools like OPA. Often, that can bring even more benefits to the effectiveness of an organization.

To be notified of future episodes: