The Open Policy Agent SDK Overview

3 min read

Authorization is a critical part of developing any application. When building an app, at some point you will want to control the data and views that a user or system has access to, and one way you can do that is by writing authorization directly into your app. However, over time this can be challenging to manage because when you make changes to your authorization policies you also need to make changes to the application. And, if you have more than one application, this problem is compounded as you may need to duplicate and maintain that code in your other applications. Open Policy Agent (OPA) helps solve this problem by allowing you to decouple your authorization policies from the application. There are a couple of architectures that allow you to do this, but today we are going to look at how to run OPA directly in your Go application using the new OPA SDK.

Why an SDK

I know what you are probably saying, we’ve always been able to run OPA as a Go library, so what makes the SDK easier to use? Well, you are right! You have always been able to run OPA as a Go library, but getting it set up often required you as the developer to know quite a bit about the inner workings and magic of OPA to get started. For example, one of the things that you would need to build into your application is a new Rego object in order to prepare a query for evaluation. This isn’t a bad thing, in fact, this way gives you as the developer a lot of control over OPA and how it runs. However, you may not want to spend time trying to tweak all those settings to get OPA working optimally, and instead, you just want to easily get OPA up and running so you can send OPA a request and get your decision back, just like when running OPA as a standalone server. This is where the SDK comes in. It is an easy-to-use set of functions that you can incorporate into your Go application to offload authorization decisions. Additionally, these functions are built in a way to help you use some of the native APIs that OPA has, making it easier to do things like connecting to a bundle registry server.

How to use the OPA SDK

Using the SDK is pretty easy, but just to make sure everything goes smoothly for you, I’ll outline its use here. The first thing we will need to do is create a context for our OPA to run using the context package. We will then need to pull in the OPA configuration file.

One thing to note here is that the OPA config can take either a JSON config or a YAML config. One of the key features of the OPA config is that it allows you to connect to a bundle server. For more information on what you can do with the OPA config, be sure to check out the documentation here. You can set up your own bundle server using Amazon S3, Google Cloud Storage, Azure Blob Storage, Nginx, or even an HTTP server, but I personally prefer to use Styra Declarative Authorization Service (DAS) as it gives me more than just bundle management but helps me manage and test out my policies as well. You can find instructions on implementing a bundle server here, or if you’d like to use Styra DAS be sure to check out the free edition here.

Another big improvement that the SDK enables is the ability to configure the OPA logger. This will allow you to bulk upload the decision logs using the decision log API. Previously, this would be something that would need to be handled by your application; now you can just configure the OPA configuration for decision logs, as seen here in the documentation, and OPA will send the logs to that service. As with the bundle server, I’m using Styra DAS to store my decision logs.

So now that I have the main function wired up to pull in the opa-config.yaml file I need to create an instance of OPA with that config.

This is where the power of the SDK shines as I’m able to create a new OPA with a standard OPA config. Now that I have an OPA set up, I can create my query using the decision options struct which takes a path for the query and an input, as an interface, like shown below. 

That’s it, now the result variable will have the result of the decision from OPA. What your policy is will affect whether the result is just a boolean or a map. To have something visual, I like to just print the decision result out to the console like so.

Sweet, so now we have a decision from OPA that we can then use in the rest of our application as needed.

Conclusion

As you can see the new OPA SDK for Go, which is in version 0.32.0, is awesome for easily getting started in your Go application to offload your app’s policy and authorization decisions without having to worry about some of the inner workings of OPA. I hope you have learned a bit about how to better integrate OPA into your Go applications.

Sign up for Styra DAS Free today!

Cloud native
Authorization

Entitlement Explosion Repair

Join Styra and PACLabs on April 11 for a webinar exploring how organizations are using Policy as Code for smarter Access Control.

Speak with an Engineer

Request time with our team to talk about how you can modernize your access management.