As your organization embraces the cloud, you may find that the dynamism and scale of the cloud-native stack requires a far more complicated security and compliance landscape. For instance, with container orchestration platforms like Kubernetes gaining traction, developers and devops teams have new responsibility over policy areas like admission control as well as more traditional areas like compute, storage and networking. Meanwhile, each application, microservice or service mesh requires its own set of authorization policies, for which developers are on the hook.
It’s for these reasons that the hunt is on for a simpler, more time-efficient way to create, enforce and manage policy in the cloud. Enter Open Policy Agent (OPA). Created four years ago as an open-source, domain-agnostic policy engine, OPA is becoming the de facto standard for cloud-native policy. As a matter of fact, OPA is already employed in production by companies like Netflix, Pinterest, and Goldman Sachs, for use cases like Kubernetes admission control and microservices API authorization. OPA also powers many of the cloud-native tools you already know and love, including the Atlassian suite and Chef Automate.
[ Also on InfoWorld: Using OPA to safeguard Kubernetes | Using OPA for cloud-native app authorization | Using OPA for multicloud policy and process portability ]
OPA provides cloud-native organizations a unified policy language — so that authorization decisions can be expressed in a common way, across apps, APIs, infrastructure, and more, without having to hard-code bespoke policy into each of those various languages and tools individually. In addition, because OPA is purpose built for authorization, it offers a growing collection of performance optimizations so that policy authors can spend most of their time writing correct, maintainable policy and leave performance to OPA.
OPA authorization policy has many, many use cases across the stack—from putting guardrails around container orchestration, to controlling SSH access or providing context-based service mesh authorization. However, there are three popular use cases that provide a good launching pad for many OPA users: application authorization, Kubernetes admission control, and microservices.
OPA for application authorization
Authorization policy is ubiquitous, because virtually every application requires it. However, developers typically “roll their own” code, which is not only time consuming, but results in a patchwork quilt of tools and policies that are difficult to maintain. While authorization is critical for every app, time spent creating policy means less time focusing on user-facing features.
OPA uses a purpose-built declarative policy language that makes authorization policy development simple. For example, you can create and enforce policies as straightforward as, “You cannot read PII if you are a contractor,” or, “Jane can access this account.” But that’s just the start. Because OPA is context-aware, you can also build policy that considers anything on the planet — such as, “Stock trades requested in the last hour of the trading day, which will result in over a million dollar transaction, can only be executed on specific services in a given namespace.”
Of course, many organizations have bespoke authorization already in place. However, if you hope to decompose your applications and scale microservices in the cloud while retaining efficiency for developers, there will be a need for a distributed authorization system. For many, OPA is the missing puzzle piece.
OPA for Kubernetes admission control
Many users also use OPA to create guardrails for Kubernetes. Kubernetes itself has become mainstream and mission-critical, and organizations are looking for ways to define and implement security guardrails to help mitigate security and compliance risk. Using OPA, administrators can set clear policies so that developers can accelerate pipeline production and rapidly bring new services to market, without worrying about operational, security, or compliance risk.
OPA can be used to create policies that reject any ingresses that use the same host name, or that require all container images to come from a trusted registry, or to ensure that all storage is marked always with the encrypt bit, or that every app exposed to the internet use an approved domain name — to cite just a few examples.
Because OPA integrates directly with the Kubernetes API server, it can reject any resource that policy disallows, across compute, networking, storage, and so on. Particularly beneficial to developers, you can expose these policies earlier in the development cycle, such as in the CI/CD pipeline, so developers can get feedback early and remediate issues before runtime. Moreover, you can even validate your policies out-of-band, ensuring that they achieve their intended effect and don’t inadvertently cause trouble.
OPA for microservices
Finally, OPA has become very popular for helping organizations control their microservices and service mesh architectures. With OPA, you can create and enforce authorization policies directly for a microservice (typically as a sidecar), build service-to-service policies within the service mesh, or, from a security standpoint, create policies that limit lateral movement within the service mesh architecture.
Building unified policy for cloud-native architectures
In general, the overall goal when using OPA is to create a unified approach to creating policy across your cloud-native stack — so you don’t have to continually manage policy in dozens of locations, using different languages and approaches, through an ad-hoc mix of tribal knowledge, wikis, and PDFs or a jumble of mismatched tools.
[ Also on InfoWorld: 7 best practices for remote agile teams ]
Aside from simplifying development and speeding delivery, this is big news for security as well, since OPA reduces the number of tools you need to check if, for instance, you suspect unauthorized access was attempted. Similarly, from both an operations and a compliance perspective, OPA makes it easier to pull and analyze information in a heterogeneous environment — helping you quickly identify problems and solve them faster.
Developers are on the hunt for a simpler, more efficient way to create and manage policy-based controls for their cloud-native environments. For many, that solution is OPA. If you find yourself touching authorization policy in multiple places, in multiple languages, or across multiple teams, OPA can help eliminate redundancy and speed delivery for you, just as it has for them.
Tim Hinrichs is a co-founder of the Open Policy Agent project and CTO of Styra. Before that, he co-founded the OpenStack Congress project and was a software engineer at VMware. Tim spent the last 18 years developing declarative languages for different domains such as cloud computing, software-defined networking, configuration management, web security, and access-control. He received his Ph.D. in Computer Science from Stanford University in 2008.
—
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.