A core element of IT security is having proper policies in place that define what is and what isn’t allowed for a given process or entity.
In the cloud-native world, where there are multiple distributed elements that can live in different deployment modalities, the challenge of defining and implementing policy is nontrivial, but that’s the challenge that the Open Policy Agent (OPA) project is looking to solve. In a session at the DockerCon Europe 2018 event in Barcelona, Spain, this week, Torin Sandall, software engineer at Strya, and Justin Cormack, software engineer at Docker, outlined how OPA can help to create and enforce security.
“Apart from the very long list of policies there are, we have to deal with the fact that we’re dealing with lots of different complicated systems, written in different languages and protocols, and the systems are changing really fast,” Cormack said.
The OPA project got started in 2016 and became part of the Cloud Native Computing Foundation (CNCF) on March 29. It provides mechanisms to help define and deploy policies. Sandall explained that OPA is an open-source, general-purpose policy engine.
“What that means is that you can basically take OPA and you can apply it to pretty much any service in any system [and] any layer of the stack to help enforce policies,” Sandall said. “The goal of OPA is to provide a tool or a library or a component that allows you to unify policy enforcement across a wide range of technology.”
Sandall said OPA has seen adoption by some big-name companies, including Netflix, which uses the technology to enforce a wide range of authorization policies over internal resources. Plus, configuration management vendor Chef is embedding OPA in its products to provide end users with policy-based control. Experience management vendor Medallia is also using OPA, to help to codify and enforce risk management policies over their infrastructure.
“There are dozens of companies using OPA today in their Kubernetes clusters to enforce admission control policies on the workloads that are being deployed on top of those systems,” he said.
How It Works
With OPA, policy decisions can be decoupled from policy enforcement, according to Sandall. As such, instead of taking policies that are specific, such as HIPAA (Health Insurance Portability and Accountability Act) or PCI-DSS (Payment Card Industry Data Security Standard) compliance, writing down wikis or putting them in spreadsheets and taking the policies and hard coding them into services, the OPA approach offloads the policy to a dedicated component.
“For example, if we were going to build a service that exposes an API that serves traffic requests, the way this would work is that whenever the service receives a request, it would execute the query against an OPA policy,” he said. “The query will ask a question like, ‘Should this request to be allowed?’”
After the query is made to OPA, it takes that query and evaluates it against a number of policies and data that it has access to. Sandall said that the outcome of that evaluation process is a decision; it’s an answer to the question of whether the requesting user be allowed to see the data or perform this operation, or deploy this container, and so on. The OPA decision is then sent back to the service to be enforced.
“The service could be an internal microservice that is built as part of a larger application, or it can be the company’s API server, or it could be a gateway, or it could be a Message Broker or a database where you’re trying to protect access to sensitive data. It doesn’t really matter,” Sandall said. “And this is why we call it general purpose, because you can take and apply it to a wide range of software.”
Policy Language
Sandall said that OPA provides a high-level declarative language for codifying answers to questions like, Can this user access this resource and perform this operation on this resource? The policy language itself is called Rego, and it has a very simple syntax.
“With Rego, because it’s just pure logic, and just pure data that we’re operating on, it’s very easy to just ask ad hoc questions of it,” he said. “This is powerful because not only can you use this in enforcement, but it’s also useful for things like audit and dry run.”
Policy today is often done in organizations with different mechanisms including access controls lists (ACLs), Identity and Access Management (IAM) and Role Based Access Control (RBAC) types of systems. Sandall said organizations can actually implement RBAC, ACL or IAM style-models inside Rego policies.
He added that RBAC, ACLs and IAM systems can be somewhat limited and restricted and don’t always cover all possible use cases. For example, if an organization needs to enforce the policy based on time of day, or based on the geographic region that the clients connecting from are based on, it can be challenging to express those things inside of an ACL or in an RBAC system easily.
“So that’s what Rego addresses. It actually lets you express those kinds of policies and compose them,” Sandall said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.