Open Policy Agent Primer
With the container and microservices bloom, we are certainly dealing with larger and larger distributed systems. The topologies continue to grow as we bake in redundancy and performance SLAs. Soon our one endpoints become many; even for the same service.
Authentication and authorization are intrinsic needs of applications. Unfortunately, everyone and everything can’t be trusted so we come up with mechanisms to limit and control access.
There are times that making a change in authorization in one service let’s say for debugging purposes would require a deployment to increase then subsequently decrease the permissions.
Open Policy Agent (OPA) strives to be service agnostic as a central source for authorization. Without a mechanism like Open Policy Agent, you would have to deploy to multiple services in your microservice(s) topology every time there needs to be an authorization change; you certainly have your work cut out for you.
Authorization Bananza
When you talk about access control in an application, you are usually talking about the dynamic duo of authentication and authorization. Open policy agent focuses on the authorization piece.
Authentication focuses on who you are, authorization focuses on what you have access to. Torin Sandall from Styra does a great job in his talk at Open Source Summit last year talking about how many times authorization changes need to occur.
Even for trusted users e.g engineers, there are scenarios where you need to increase what you have access to in applications and application infrastructure. Debugging/mimicking users is a good example of how authorization changes can certainly stack up. Different services might be using different authorization providers. When you take a look at the lowest common denominator, Open Policy Agent fits in pretty nicely with the authorization decisions that have to be made thus centralizing those decisions.
Enter OPA
Open Policy Agent is a CNCF Incubating project in terms of CNCF maturity. OPA decouples policy decision-making from policy enforcement. There are a few key terms to be familiar with OPA. The first is the data you supply to OPA which is in JSON. The data is what a decision is being made off of. The second is a query input which is also in JSON. The query input directs the decision e.g what decision needs to be made. Lastly is the policy which is in Rego, a declarative language for OPA. The policy is the logic that needs to be executed.
When executing an OPA based decision, your calling system or process needs some way to parse the answer. For example, if Jane Q Devops has access to employee salary which could be “true/false” or “Jane Q Devops” as part of a response list. Getting started with OPA, a great resource is the Rego Playground where you can quickly mock data and policies. Getting OPA onto your Kubernetes Cluster is a breeze with Harness.
Your First OPA Install
In this tutorial, we will be installing OPA’s GateKeeper which is a policy controller deployed on Kubernetes which currently requires a 1.14+ Cluster per the project. Like always can follow along with the video and/or the blog post.
The first step of getting a Harness Delegate installed in your Kubernetes Cluster is pretty straight forward.
Setup -> Harness Delegates -> Download Delegages + Kubernetes YAML
Name the Delegate “opa”.
Hit submit to download. Expand the tar.gz.
Inside the delegate folder, run kubectl apply -f harness-delegate.yaml to install the delegate.
In a few moments, your Harness Delegate will be available.
Wiring a Kubernetes Cluster is simple especially with a Harness Delegate running inside the Kubernetes Cluster.
Setup -> Cloud Providers + Add Cloud Provider
Add a Kubernetes Cluster named “opa_eks_cluster”. Make sure to Inherit Cluster Details from the selected Delegate [opa].
Once you click Submit, your Kubernetes Cluster has been added.
With the Cluster added, you can deploy the GateKeeper installable.
You will need to link the GitHub Repository for the GateKeeper Project.
Setup -> Connectors -> Source Repo Providers + Add Source Repo Provider
Wire in the Git Repository for the project [https://github.com/open-policy-agent/gatekeeper]. You will need to enter your GitHub credentials.
Next, you will create a Harness Application to do so.
Setup -> + Add Application “OPA101”
With the Application added, wire in the Kubernetes Cluster as a Harness Environment.
Setup -> OPA101 -> Environments + Add Environment
Add an Environment named “opacluster”.
Add an Infrastructure Definition linking your Kubernetes Cluster with + Add Infrastructure Definition.
Define the Deployment Type as Kubernetes [not Helm]. Currently, the OPA GateKeeper Helm Chart is a Helm V2 Chart which requires Tiller. Harness has the ability to deploy Helm V2 Charts without the use of Tiller.
With the Infrastructure Definition wired, time to wire a Harness Service, which will be the OPA install.
Setup -> OPA101 -> Services + Add Service
Add a new Service called “opa_install”.
Once you hit Submit, you can link to the Helm Chart that is in OPA GateKeeper’s repository. In the middle of the Service, click on the ellipses to Link Remote Manifests.
Can link the Remote Manifest of “Helm Chart from Source Repository”. [https://github.com/open-policy-agent/gatekeeper/tree/master/chart/gatekeeper-operator]. The Branch will be “master” and the path will be “chart/gatekeeper-operator”.
Validate the Manifests look good.
Next, create a Harness Workflow based off of the “opa_install” Service.
Setup -> OPA101 -> Workflows + Add Workflow
Create a Harness Workflow named “opa_install” as a Rolling Deployment with Service “opa_install”.
With the Harness Workflow setup, time to give OPA a deploy. Click on the blue Deploy Button.
Get Ready for the OPA Install.
Watch and prosper as you are along your OPA Journey.
The Harness Platform makes adopting new technology easier by a consistent way to deploy new ideas and methodologies.
Harness: Your Partner in Paradigm Shifts
The only constant in technology is that there will be change. Open Policy Agent represents a new approach for a problem that is rearing its head more and more at scale. The Harness Platform is purpose-built to deploy new methodologies with confidence. A leader in the Open Policy Agent space, Styra, like Harness, is an Unusual Ventures backed company. Both are visionaries in their own domains. Feel free to sign up for a Harness Trial today. We would love to hear from you on what you are working on around OPA in the Harness Community also.
Cheers!
-Ravi