Intellyx BrainBlog: The Perks and Pitfalls of Homebrewing Permissions with Open Source

As a young homebrewer, I enjoyed making strange beers that I just couldn’t find in the store. I’d pride myself on finding exotic ingredients and employing unconventional brewing methods. All part of the story as I poured it for my friends.

Homebrewing beer can be unpredictable, but the cost of failure is rather low.

“Don’t worry, if I messed up this recipe, the worst it can do is leave a bad aftertaste...”

While the stakes for homebrewing permission frameworks may seem high, it’s not an uncommon practice. Conventional identity-oriented access controls provided by IT often don't support the notion of microservices talking to each other in cloud infrastructure properly. For this reason, many cloud native development projects whip up their own authorization methods to get application work done.

What are some tips for maximizing the chance of success for do-it-yourself permission efforts while minimizing project overruns and security risks?

Brew your own permissions, with a little help

Much of the science of brewing has become common knowledge. With readily available advice and the right ingredients, world-class results are now just a recipe away.

Cloud native applications are complex, fast-changing, and based largely on open source underpinnings. The biggest IAM and security vendors often have proprietary elements in the mix as a means of market share protection, which encourages developers to take a do-it-yourself approach to permissions.

Encouragingly, when building cloud native permissions, there are already many proven recipes for success, so developers don’t have to build it all by themselves. 

Cloud native software development leans on open source as a core tenet – and therefore, we can tap into the expertise of a dynamic, fast-growing community of contributors who are driving open source solutions for implementing an authorization layer with advanced permissions that can deal with ephemeral clusters, APIs and remote teams. 

Here are a few important things to look out for in forming your own bill of materials for permissions, a brew-bucket list as it were.

Pour in open source policy

Identity tools can determine which users can access a system, and authentication is useful for securing the perimeter of an application. Still, cloud native applications have a deep need for stronger authorization to control which actions users/services can take on what resources to get work done.

It is straightforward to homebrew a single permitted behavior – say, a qualified auditor asking an HR service for an employee’s salary. That’s fine for a prototype, but once there are thousands of permutations of interactions between users and microservices, there will never be enough time to write or update so many individual permissions.

We need permission rules that are more flexible to avoid manual rewrites. Right on time, the open-source OPA (Open Policy Agent) provides an excellent CNCF-graduated starting point for this, allowing developers to use the declarative Rego policy language to write authorization rules that services of almost any type can make requests against.

Separate rules from implementation

In conventional apps, authorization schemes are often associated with the target environments they are running in. For instance, a user’s authorization status could be maintained as a token for the duration of a particular session running in a Chrome browser and accessing an open connection to a particular Linux container or a database. 

In cloud native applications, the statefulness of that user’s session goes out the window, as API calls and data get passed among ephemeral, possibly widely distributed microservices that each perform their own functions as workloads. Since it’s no longer relevant where the physical implementation lives, authorization has to be maintained separately.

Rather than coding a new rule for every unique implementation, OPA allows ‘policy as code’ that is inherently decoupled, allowing permissions to be written and changed independently from deployment. To the rest of the architecture, the OPA agent is just another microservice that is called on to make decisions on permissions.

Layering on an event-driven scale

Event-driven architectures (or EDAs) include API layers that can ingest and process streaming data services at scale. Event-driven integration is becoming popular for mission-critical applications where time is of the essence. EDA actions include not just responses to requests (ala REST-style integration) but reactions to asynchronous events.

OPAL (or Open Policy Administration Layer) is an open-source project that makes OPA agents event-driven. OPAL listens for any changes to code within the org’s application repository, as well as changes to any connected APIs, third-party services, cloud storage volumes and, databases. If an asynchronous change event occurs, OPAL can drive updated permission policies to sync up any OPA agents in real time.

Permission policies and the underlying access data for groups of users and systems are portable across applications and tenants – even as underlying microservices, clusters, and APIs are constantly decommissioned and renewed. In a meta-sense, automatically propagating authorization to each ephemeral service extends the dream of dynamic cloud native architecture at the permissions layer.

Development teams eliminate toil by storing OPAL policies in cloud repositories and merging them with GitOps delivery processes. OPAL can automatically update OPA permissions with each pull request without needing to migrate and potentially expose sensitive user and company data.

The Intellyx Take

Much like grinding grains for beer or coffee, it’s important to get the granularity right when brewing up a cloud native permissions strategy that depends upon open source software. 

You don’t want to start down a path of setting policies that are too fine-grained, which will require manual intervention for each action and throttle developer productivity. At the same time, you want a centralized plan for open source permissions management that is decoupled from infrastructure and coarse-grained enough to adapt to changes and events.

In our next chapter of this series, we’ll discuss how some leading companies augment their initial homebrewed cloud native authorization efforts with a SaaS-based policy control platform like Permit.io that has expert practices for managing OPA and OPAL built in.

Copyright ©2022, Intellyx LLC. At the time of writing Permit.io is an Intellyx customer. Intellyx retains final editorial control of this article.