Styra is the company behind the open source Open Policy Agent (see openpolicyagent.org for more info). It enables policies and authorization across your IT ecosphere.
Policies
A policy is a set of rules. It is connected to a specific application. It answers questions such as “what users may access specific functionality in this application?”, or “in which tables in a specific database is privacy-sensitive information stored?”. An often used policy is authorization. It describes who may access which functionality within what application.
The Open Policy Agent
In 2016, the first commit of the OPA code was done. The project grew rapidly in the following years, and was added to the Cloud Native Computing Foundation sandbox in 2018. The sandbox is an instrument that helps projects in their early stages to gain visibility and provides nourishment, as CNCF describes it, for example by offering services such as a service desk.
On the 4th of February 2021, OPA graduated. Graduation is a good indication for widespread adoption and maturity of a specific project (and its supporting community).
Why OPA
Torin Sandall, co-founder of the OPA project, states “What may have worked for authorization before, no longer worked in a diverse cloud native environment.” Business functionality running on a container platform may be supported by tens, maybe even hundreds of tools that work together to provide a seamless experience for the end user, developer and operator. Tools change over time, with new versions sometimes appearing just as fast as the agile team deploys new code.
OPA attempts to solve the headaches of integrating authorization for these tools, by providing a central control plane. By positioning OPA as an open source project, the community at large was challenged to create integrations to the Cloud toolkit, and so they did.
A typical use case
Consider a modern internet facing software application, which consists of several microservices providing functionality to an end user and a backend with access to data stores, payment engines, connectivity to external applications, maybe even Facebook integration. Traditionally, such an application was built and managed by one team which provides a relatively clear overview of who controls what, and who has access to what. In a modern environment, services are built by separate teams and they change over time (are replaced with new functionality, or disappear all together). Providing access control in such a dynamic environment calls for a centralized component, which is exactly what OPA is.
How does OPA work?
OPA works as an agent between a (your) service and a set of policies and optional data. The diagram below describes this.
A service queries OPA with a request for a decision. This first step is important, as it basically moves policy decision and execution from your environment to that of OPA. It then reads a Rego policy and enriches this with additional input in JSON format. Input originates from external applications or services, such as an LDAP server. This connection to external systems is important, because it enables OPA to base decisions on context. OPA then returns the decision as either an allow or deny.
Result in JSON or YAML
The decision request made by a service is in JSON or YAML (converted to JSON by OPA) format. It is up to the developer to specify what output he or she wants as a decision: a yes or a no string, a 0 or 1.. This versatility is a great advantage of OPA.
Rego
In OPA, policies are declared in a declarative, descriptive (query)language called Rego. Rego provides a solution for working with human readable, machine executable policies that are difficult to create in regular programming languages. Basically a query returns either true or undefined (unless there is a default value for undefined). On Medium, there is a great article that delves deeper into the language.
Architecture
Several ways exist in which you can use and deploy OPA in your IT landscape. If your environment supports Go, you can import and use OPA as a GO library. This does require some tweaking and more knowledge of the inner workings of OPA than just running the tool as a standalone server, which is the other option. If you prefer less tweaking but do have GO in your environment, you can also use the SDK. One of the advantages of using the SDK is that it enables a logging mechanism.
OPA and domains
OPA can be used to connect to and control policies for various domains, which are listed in the picture below: containers, servers, cloud infrastructure and microservices. Each domain uses a specific method for connecting, such as directly (microservices), by means of an orchestrator (containers and cloud infrastructure) and ssh (servers).
Deployment
It is possible to (from an infrastructure perspective) deploy OPA in a Docker image (images are available on Docker Hub), on top of Kubernetes or as a standalone application. Which deployment method you prefer depends on the (performance) requirements of the application or service you are responsible for. In order to prepare for performance, you need to consider other deployment methods. Five such methods exist, which are described in great detail in a Styra blog. The challenge is to make sure that OPA is not a bottleneck in the performance of your service.
Rego Playground and REPL
In order to play around with Rego, Styra has created the Playground. It is allows you to test your policies in an actual environment. There is an article describing the functionality of the initial version of the playground.
Another way for testing or simulating OPA queries (or just playing around to find out how OPA works) is by using REPL, which stands for Read-Evaluate-Print-Loop. You do this by starting OPA without the server tag (by typing opa run in the terminal). The REPL allows you to query anything inside OPA.
OPA and Styra DAS (and pricing)
On top of OPA, Styra offers a control plane called DAS (Declarative Authorization Service). It is available in a limited, free version (with 20 enforceable rules and the ability to manage two systems) or in an enterprise version, which costs around $2,000 (per year, for 50 nodes) to run on Amazon.
OPA ecosphere
OPA integrates well with a growing set of applications and systems. A list including examples is available. In this comprehensive overview, you will find links to the integration code, documentation and examples on how to integrate.
Learning OPA
Styra offers a lot of resources that help you understand what OPA is and how you can use it in your environment. There is the aforementioned Playground, extensive documentation, but also an Academy offering free training.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
