Improving Kubernetes Security with Open Policy Agent (OPA)

Many multinational organizations now run their applications on microservice architecture inside their cloud environments, and (many) administrators are responsible for defining multiple policies on those environments. These giant IT organizations have extensive infrastructure systems and their systems have their own policy modules or their own built-in authorization systems. This is an excellent solution to a policy issue at enterprise scale (especially if you have the investment and resources to ensure best practice implementation), but such an overall ecosystem can be fragmented, which means if you want to improve control and visibility over who can do what across the stack, you would face a lot of complexity. 

Why We Need OPA

Doing a lot of policy enforcement manually is the problem of the past. This does not work in today’s modern environments where everything is very dynamic and ephemeral, where the technology stack is very heterogeneous, where every development team could use a different language. So, the question is, how do you gain granular control over manual policies to automate and streamline their implementation? And the answer is with Open Policy Agent (OPA).

OPA provides technology that helps unify policy enforcement across a wide range of software and enable or empower administrators with more control over their systems. These policies are incredibly helpful in maintaining security, compliance, standardization across environments where we need to define and enforce such policies in a declarative way. 

What Is Open Policy Agent (OPA)?

Open Policy Agent (OPA) is a domain agnostic, general-purpose policy engine. OPA gives you the ability to decouple and offload policy decision-making from policy enforcement. Suppose you were building microservices in your organization. In that case, you might have to decide when that microservice receives API requests, whether or not to allow the request based on all kinds of rules from within your organization. So, what OPA gives you is the ability to offload that decision-making process to a dedicated engine so that your administrators and your ops teams and you have more control over the service at runtime. The goal of OPA is basically to help unify policy enforcement across a wide range of technology. That is why we call OPA general purpose. OPA is also domain agnostic as you can use it across the stack and various kinds of services, systems, layers.

There are multiple options for running OPA. 

• Download OPA binary, assign executable permissions and run. 
• Run OPA via Docker, docker images are available at DockerHub as openpolicyagent/opa
• Try opa eval through the command line to interact with OPA. opa eval is the swiss-army knife to work with rego expressions and policies in OPA
• Use REPL (Read-Eval-Print-Loop) or interactive shell to run, test policies on the fly
• Run OPA as a server and execute queries over HTTP
• Embed OPA as a library inside Go programs

Features of OPA

Below are the most popular OPA features:

• OPA uses Rego language, which is very easy to read and write policies.
• All the traffic between the client and OPA is encrypted. Clients get access to only those APIs that OPA allows, that is why OPA is very secure.
• Implementing OPA does not affect your application’s SLA as there is no downtime, this makes OPA fast and reliable.
• Using domain-agnostic APIs, we can integrate OPA with multiple tools like Docker, Kubernetes, Terraform, Prometheus, Grafana, ISTIO, and many more.
• Supports REPL (Read Eval Print Loop) to run quick experiments for developing, running, testing policies.
• We can implement OPA with custom built-in functions and plugins.

Use Cases of OPA

There are a whole range of different use cases where we can use OPA:

• Use OPA for problems around service-level authorization for controlling who can do what at different parts of the stack. OPA can decide which microservices can talk to each other, which application components a microservice has the authorization to access, etc.
• Enforce policies across organizations for end-user authorization. OPA decides which user should have what level of access in the application. 
• Use OPA as a Kubernetes admission controller for enforcing Kubernetes policies. These policies are around resource usage by specific labels in the cluster, request, and limits on cluster resources, access of not-root users, etc.
• Use OPA in microservice API authorization for enforcing all kinds of config validation use cases in CICD pipelines or control SSH and pseudo access at the host level.

How Does OPA Works

OPA has three major components—data, query input and policy. Data is the facts about applications or services running in the environment. Query input has a JSON format that specifies the questions that OPA has to answer for decision-making. The policy is the computational logic that executes depending on the data and query input it receives from OPA. These are the building blocks of OPA. 

We can integrate policies in OPA into our service as a library or we can run it next to our service as a daemon. Whenever your service receives an event or receives a request, that service needs to make a policy decision by executing a query. OPA will check if this request is allowed or not. In the case of the Kubernetes API server as admission control, OPA will ask if a request should be mutated or modified in any way or not. So, when the service executes a query, OPA provides a comprehensive range of attributes and you can actually provide arbitrary JSON attributes. The tool will then take those attributes and evaluate them against the policies and the data that OPA has access to. Finally, OPA will produce a decision like allow or deny the request, and the service has to enforce the decision. 

In doing this, OPA has essentially decoupled policy decision-making from policy enforcement, meaning that we do not have to intimately know the policy rules and constraints to operate successfully. Also, we do not have to hard-code all the policy logic inside of applications and platforms manually. 

Conclusion

In this modern IT world, where the applications and environments are so dynamic now, using OPA is necessary to automate and streamline policy implementation. Optimize OPA to enforce policies across your applications, services, Kubernetes clusters, etc., to improve your security and compliance stance inline with industry standards.

Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.