Why Portability is Key to Better Productivity and Security

Least hot take of all time: Interruptions and rework are the worst. The modern dev pipeline is purpose-built to make collaboration easier and allow individuals and teams to work together to contribute to regular code pushes. This of course means lots of invention, feedback, creativity and iteration, all of which work best when they can be the point of current focus. Interrupting the process of creating new ideas because individuals or teams have to go backward and make changes based on config errors or compliance issues is frustrating. It’s also slow. No good.

The good news? Implementing automated policy checks at multiple places in the pipeline can shift checks left, speed feedback cycles and dramatically reduce context switching. To prove this point, let’s have a little before and after comparison.

On Monday, I spend the day thinking through and writing a cool new customer feature, Feature A, and check it into Git when I’m finished.

On Tuesday, I spend the day writing a different feature, Feature B, that has nothing to do with Feature A. When I am done, I check it into Git. I attend some meetings, and I’m on to my next task, Feature C.

On Wednesday, I finish the task we started on Tuesday, Feature C, and check it into Git. I start working on another feature, Feature D, only to receive some config error feedback on Feature A in the middle of the day. Now, I have to stop working on Feature D and go back to focusing on whatever it was that I thought up on Monday about Feature A. I was in a meeting with the UI team, and we were really getting somewhere, but now I am interrupted. I queue up my Feature A brain to address the needed changes. The time between checking in A and finding out there’s some compliance issue about A has not only interfered with my work, it also hurts the team, since I’m now distracted in a collaboration meeting.

What if I could receive feedback in real time? Or at least, while I was still thinking about the code I was contributing? My week would look a lot different:

On Monday, I spend the day writing code for a cool new customer feature, Feature A, and check it into Git when I’m finished. I immediately get the results of a policy check that tells me I misconfigured a workload to run as root, I named it incorrectly and I specified an ingress I didn’t need. Oops.

I make the changes and resubmit. Then I am on to the Feature B, confident that I will not be interrupted about Feature A compliance issues later in the week or ever again!

And so it goes for each check-in: I get feedback while I am still thinking about the work, not hours or days later. I am more productive, less frustrated and better able to focus my efforts on what matters.

What’s more, that same policy can give feedback to my platform team. Later in CI/CD, when it is time to push the build, the exact same compliance checks need to be performed to ensure that only safe code makes it into our app. I don’t need to be bothered, but the DevOps team can see, across all the teams that are working on the app, that all code is checked, safe and in compliance with our internal and external regulations. This proves that things are working as intended. (Did I mention that I don’t need to be bothered at this point?)

The same checks can be performed at various stages, at different times, and with output for different audiences — Dev, DevOps, Compliance, Cloud team, etc., all with the same exact policy automation — thanks to policy portability.

Portability is important for policy, because it leads to increased productivity and better security.

For example, teams can take a policy that usually would be applied later in the pipeline and apply it while writing code (shifted left). Developers get feedback earlier and fix problems sooner. Ops teams need to see the results of those early checks and then likely need to check again at, say, admission control time to satisfy compliance regulations. And then the systems/cloud team may need to see the checks in yet another place (Terraform Run time, for example) to know that there are no errors before pushing out a software update to customers.

The same policy intention has to be implemented at multiple points, but rewriting that policy four times and implementing it in four different places is a recipe for disaster. Not only does it waste time and lead to mistakes as teams retype policy, it means ongoing management hassles because any small update needs to be made, and checked, in many places. Instead, implementing the same checks to the same code, in multiple places, eliminates the rework and the risk, all while achieving the goal of minimizing interruptions for developers.

Better productivity, better security, better compliance — is it really possible? It is, with some key technology choices along the way:

1. Tooling needs to catch up. You can’t achieve fast feedback cycles with slow point-and-click UIs that are designed for non-technical users. The tooling needs to fit seamlessly into the developer’s workflow, which means not just policy, but policy-as-code, treated the same way all other code is treated.

2. Underlying policies need to be portable. You need to be able to take the policy and execute it in places you might not have thought about before, for example, in an IDE on a developer’s laptop. Again, centralized, UI-based tooling doesn’t lend itself to that.

3. Culture has to adapt. Once you have portability in place, “shift-left” becomes a lot easier because running on a K8s cluster — or offline for scanning purposes, or inside a CI/CD pipeline, or on a developer’s laptop — all become the same problem. But of course, all the various teams need to agree on what compliance checks work and what parts they are responsible for. This can’t be a “push everything onto the developers” problem, but rather a shared responsibility, with multiple checkpoints to ensure that all teams work together toward a common and well-understood goal.

This portability has been a critical part of implementing Open Policy Agent (OPA) in the real world. OPA lets you write policy-as-code the same way, no matter where you decide to place the check, whether that’s K8s admission control, peer review time or on a developer’s laptop. It’s not often that a security or compliance solution can also have a productivity benefit for developers, but in this case OPA does indeed minimize interrupts/rework and prevent errors that lead to risk.

This article first appeared in The New Stack on November 5, 2021.

New to Open Policy Agent? Sign up for the Styra Academy, which has free OPA tutorials, today!