Open Policy Agent’s Mission to Secure the Cloud

If cloud computing and software development are to continue to thrive, more cooperation is needed to ensure our shared systems are secure.

To do that, we need to agree to implement industry standards in vital areas. The Open Policy Agent (OPA) is an important step in that direction, one that hasn’t received anywhere near the attention it deserves.

OPA is an open-source tool that enables the enforcement of a wide range of policies across domains and all layers in the stack. This policy engine supplies users with greater control over their environment while eliminating the need to write a different policy language, API, or model for each product and service.

Consider the time and energy many of us sink into policy management. We must often implement tools designed to root out network vulnerabilities, partly because we lack practical means to test if a policy will work everywhere. Too many resources are dedicated to authentication and compliance instead of on our core products.

OPA helps eliminate these problems, as well as many others.

The technology made news in 2018, when the Cloud Native Computing Foundation (CNCF), announced it had agreed to host and “sandbox” the OPA project. The CNCF is the vendor-neutral home for many of the most important open-source projects, including Prometheus and Kubernetes.

At KubeCon+CloudNativeCon San Diego this past November, OPA generated a lot more chatter after companies such as Pinterest, Yelp, Microsoft, Google, and Trip Advisor shared use cases and offered testimonials.

Testimonies

What we’ve learned so far about OPA is that it’s a flexible and handy tool, enabling policy control across containers, servers, microservice APIs, and public cloud infrastructure. One of the best features of this general-purpose policy engine is that it doesn’t require users to enforce a specific set of rules.

OPA’s policy language, Rego, enables users to easily define rules. A service operator writes the rules that dictate who gets what access and where. An API request is queried by OPA and determines whether to grant the request or not, based on the rules provided by the operator. OPA decouples policy from a service’s code and enables reviews and testing without sacrificing availability.

Large numbers of security-conscious and heavily regulated enterprise companies at one time spent many hours auditing software releases, CNCF executive director Dan Kohn explained at the latest KubeCon. In addition to consuming a lot of time, the audits weren’t always reliable. Kohn says as more of these enterprises move to microservice architectures, instead of one big monolith, they now have potentially hundreds of microservice applications to split up.

As enterprises move from quarterly or monthly software installs to as many as 50 deployments per day, the old manual review system becomes untenable.

“The simplest pitch for OPA is to say, ‘We’re taking all that functionality that manual auditors and reviewers used to do and putting it into software,” Kohn said. “And we’re going to monitor that the software is doing what it’s supposed to do in terms of enforcing the rules.”

Keep in mind that OPA is a work in progress, and implementation isn’t without its challenges. A few of the managers who shared use cases at KubeCon cautioned the audience to watch out for some of OPA’s complexities.

“Avoid our mistakes,” William Fu, a Pinterest software engineer, jokingly told KubeCon attendees. Fu advised that using the bundles provided by OPA saves time.

When authorizing access, Fu said creating an on-off switch is important for dealing with emergencies. He added that Pinterest wanted to see something akin to a sliding control bar that would give operators the ability to authorize varying traffic percentages.

Fu also recommended enabling engineers to author their own policies.

Luke Massa from TripAdvisor spoke about the importance of writing tests when deploying OPA.

“Writing tests as you go helps codify your understanding of OPA,” Massa told the crowd. He added that not only does test writing early help operators gain comfort writing in Rego but it also makes adding new policies easier and less stressful.

While the cost of implementing OPA is a little high today, the technology pays for itself by providing more control and helping to secure systems. As OPA continues to be refined, we can expect implementation costs to fall, making an investment in OPA easier to justify.

Cloud infrastructure is massive and complicated and requires more sophisticated protections than what we have now — especially as we see greater numbers of large companies embrace Kubernetes.

Torin Sandall, an engineer at Styra, the company that founded OPA, said last year that the project’s development is seeing a growing number of contributors. He also made the endgame for OPA clear.

“We’re seeing more and more security vendors get interested in OPA,” Sandall said. “You know that is going to be instrumental in the long run to achieving the goal of unifying policy control across a number of different systems. There’s never going to be one vendor that rules everything, and there’s always going to be an amalgamation of different technologies.”

”The best that we can do, I think, is provide this building block that can be embedded all over the place,” he said.

OPA has the potential to become an important industry standard. Adopting vendor-neutral standards has typically enabled a flourishing technology ecosystem to grow around them. Where would we be without Ethernet, TCP/IP, and HTML?

What’s clear is that the more people who contribute to developing technologies like OPA, the more we all benefit.

KubeKon+CloudNativeCon and CNCF are sponsors of The New Stack.

Feature image: Open Policy Agent