TLDR; Open source code promotes innovation, collaboration, and transparency in software development. OPA is a powerful policy engine that helps manage access control in microservice architectures, and has been adopted by major companies such as Netflix. However, OPA alone may not be sufficient for some policy enforcement needs. OPAL, an open-source project, complements OPA by addressing these limitations and is already being used by companies like Tesla, Cisco, and the NBA.

Why Open Source?

Open source code plays a crucial role in the world of software development. It allows developers from around the globe to access, modify, and contribute to the source code of various projects, resulting in a powerful knowledge-sharing ecosystem. By making software freely available, open source promotes the rapid evolution of technology and ensures that solutions are accessible to a broader audience. This collaborative approach helps accelerate problem-solving, encourages the development of better and more reliable software, and drives the growth of vibrant developer communities. Furthermore, open source enables individuals and organizations to build upon existing solutions, reducing the duplication of effort, lowering entry barriers, and empowering even small teams to create powerful, feature-rich applications.

Access Control is Hard

Developing access control is not an easy task, especially considering today’s microservice architectures: many authorization points are required by design, and changing requirements and regulations from various departments constantly challenge the solution. Moreover, even a minor bug in this sensitive layer can have a devastating effect on your organization.

To successfully build an access control layer, it is necessary to embrace some best practices — One of which is to decouple policy from code. This can be done using a policy engine such as Open Policy Agent (OPA).

OPA: Separating policy from code

OPA, an all-purpose policy engine OSS project, was introduced several years back to reinvent how we enforce permissions throughout the stack. Since its inception, OPA became a CNCF graduate (alongside Kubernetes) and was battle-tested by major players like Goldman Sachs and Netflix.

OPA is very efficient and built for performance — It keeps the policy and data for which it needs to evaluate the rules in the cache, and supports having multiple instances as sidecars to every microservice, thus avoiding network latency.

OPA’s policy rules are written in Rego — a high-level declarative (Datalog-like) language. Here is an example:

default allow = false
allow = true { 
 input.type == "writer"
     input.action == "create"
     input.resource == "article"
}

Here is a high-level overview of how OPA works.

OPA is really powerful and can solve a lot of policy-related issues. Having said that, for some policies, OPA isn’t enough, and another solution is needed.

Taking OPA to the next level

While OPA is a strong candidate for all permissions-related needs, there are cases where OPA might not be enough.

For example, let’s say that our policy requires that a user will be a subscriber to see parts of our site. In this case, to make a policy decision, we need to know the user’s subscription status from our billing service (e.g. PayPal or Stripe) and know every time it is changing: a new subscriber expects immediate access to our site, and a churned user should lose access on the spot.

To make the data accessible to OPA, we will need to develop a pushing mechanism that will update OPA in real-time, which requires additional planning and development.

There are additional cases for which OPA isn’t enough:

• When your policy relies on multiple data sources for decisions, you need to use the bundle API, which is not really straightforward to implement.
• When you have multiple OPA instances, you need to build your tools to keep them in sync.

OPA was adopted by giants like Netflix, and they faced the same challenges. Let’s take a look at how they overcame their issues.

Learning from giants — Netflix & OPA

There are three things that Netflix implemented in their architecture that utilize OPA, which allowed them to have an effective solution.

1. Running Multiple OPA Instances Simultaneously: Netflix’s architecture incorporates numerous OPA instances, each operating locally on a service’s pod and equipped with its own authorization agent. By doing so, they significantly reduce network latency when querying OPA, ensuring a smoother and more efficient authorization process.
2. Real-time Policy and Data Synchronization: Netflix’s authorization system relies on certain inputs not included in OPA’s data, such as employee-department associations. To address this, they developed a microservice called an “Aggregator” that gathers data from various sources and keeps it up to date in real-time. Additionally, they implemented another microservice, the “Distributor,” which ensures that all OPA instances remain synchronized and current.
3. Empowering Developers with Self-service Policy Creation: As a large organization, Netflix needed a scalable solution that granted developers the autonomy to define policies for their respective services. To achieve this, they designed the “Policy Portal” — a user-friendly website that automatically generates Rego code based on user-defined rules. Once a policy is created or updated, it’s versioned and stored in a dedicated policy database.

There is one issue with this solution — Netflix never made it public.

That’s what OPAL is here for!

Open Policy Administration Layer (OPAL) is an OSS project invented to aid with OPA management, essentially open-sourcing Netflix’s solution. OPAL is an administration layer for the OPA agents, which keeps them updated in real-time with data and policy updates. Since its creation, OPAL has been adopted by major players such as Tesla, Cisco, Palo Alto Networks, multiple banks and even the NBA as the administration layer for their OPA agents.

OPAL offers two remarkable features that have garnered widespread appreciation among numerous organizations:

• The ability to monitor a specific policy repository (like GitHub, GitLab, or Bitbucket) for updates. It does this by either using a webhook or checking for changes every few seconds. This makes the system act as a Policy Administration Point (PAP), which sends the policy changes to OPA, the Policy Decision Point (PDP) in this case. This ensures that OPA is always up to date.
• The ability to track any relevant data source (API, Database, external service) for updates via a REST API, and fetch up-to-date data back into OPA.

Designing access control and managing permissions for cloud-native or microservice-based products can be a complex endeavor. The inherent nature of distributed applications and microservices demands numerous authorization points, while evolving requirements from different departments continuously put pressure on every authorization solution. Furthermore, even the slightest oversight in the authorization layer may result in severe consequences for your application, leading to security vulnerabilities and potential privacy or compliance issues. Therefore, it is vital to diligently approach and handle these challenges to ensure robust and secure applications.

You can join OPAL’s Slack community to chat with other devs who use OPAL for their projects, contribute to the Open-source project, or follow OPAL on Twitter for the latest news and updates.

Access Management - from scary to simple with one open-source tool was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog is based on the video “Build Authorization like Netflix with Open Source”

Netflix has over 220 million active users and is worth over 100 billion dollars. With such an enormous user base, they are responsible for managing a vast amount of personal information. A big part of that is ensuring relevant people have the permissions required to access that information, while others do not.

How does Netflix handle the challenge of managing its authorization? Where does open-source come in? How can you adopt this solution? (Or build something even better) Let’s find out.

With Great Power -

In 1997, Netflix was little more than an upstart DVD rental company. Fast forward two decades, and Netflix has become one of the biggest TV and movie studios in the world.

As a company grows, the responsibility it has towards its customers grows as well, and security becomes increasingly important with every new user joining the platform.

The first challenge is authenticating users when they log into the system — that’s authentication. Once users are in the system, the second step is to decide what they have access to — that’s where authorization comes in.

Why is authorization critical?

Authorization (Not to be confused with authentication) is the process of managing access to resources based on a user’s identity and the permissions assigned to that identity. This is typically done by comparing a user’s credentials against a set of rules (policies) to determine what they are allowed to access.

Authorization is crucial for Netflix — not only to make sure only paying customers have access to shows but also as a means of maximizing potential revenue. How, you may ask? By being able to tailor shows based on specific countries or user interests, by offering purchasing power parity — adjusting their prices in accordance with income levels per country, and more.

Authorization is a complicated task

Writing authorization policies is quite a complex task. To address this issue, Netflix chose Open Policy Agent (OPA) — an open-source general-purpose policy engine that unifies policy enforcement across the stack.

OPA provides a high-level declarative language called Rego that lets you write policy as code, along with a simple API to offload policy decision-making from your software (As pairing authorization logic with application logic is a bad idea). OPA can be used to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more.

The thing is — Rego is quite hard to master, thus limiting the ability to manage policies to a very small chunk of people. Netflix encountered a problem where very few people in the organization could actually write Rego policies, yet they wanted to distribute the ability to create and manage policies across the organization.

How did Netflix solve its authorization problem?

Netflix built a UI on top of OPA, which allowed them to create Rego policies and simplify the process. That solved the issue, but then another problem emerged:

Once the policy was in place, did they actually capture its intent? They knew in plain English what they wanted to achieve with the policy, and they proceeded to define it in the UI, but they didn’t know if it would actually perform. To solve this issue, Netflix ended up building unit-testing mechanisms for the UI.

You want a policy to be implemented in the system? Write it, write a test for it, and make sure that the test passes. Before you save and the policy change gets pushed, all the tests are run, and then if they all pass, the changes get applied to production. Voila.

This allowed Netflix to create a solution on top of open-source components, saving them much of the effort it would take to build a homebrew authorization layer from scratch. Unfortunately — Netflix kept this solution to themselves, never exposing it to a wider audience.

A great video by the CNCF where Manish Mehta and Torin Sandall from Netflix tell the story of how Netflix solved authorization with OPA in much more technical depth:

How Netflix Is Solving Authorization Across Their Cloud [I] — Manish Mehta & Torin Sandall, Netflix

How can I implement this solution?

While Netflix never open-sourced their solution, the solution they built on top of OPA inspired another open-source project: OPAL

OPAL (Open Policy Administration Layer) is an open-source administration layer for OPA that allows you to easily keep your authorization layer up-to-date in real-time. As you push updates to your application’s stores (e.g. Git, DBs, S3, SaaS services) OPAL will make sure your services are always in sync with the authorization data and policy they need.

A similar high-level architecture to Netflix’s is expressed within OPAL:

The Aggregator is the OPAL server, the Distributor is the split between a server and a client, and the Updater is the OPAL client.

You can learn more about OPAL’s architecture here

Using this inspired approach allows OPAL to aggregate policy and data from different sources, and integrate them seamlessly into the authorization layer in real-time. The project is free and available to everyone as a public project and is already being used by companies like Tesla, Cisco, Palo Alto Networks, and Walmart.

If you want to go even further, Permit.io provides a no-code UI that allows you to create, manage and enforce Rego policies and is based on a combination of OPA and OPAL. Allowing you to implement complex RBAC and ABAC policies into your application, and manage them with a simple UI anyone in your organization can use.

Help OPAL grow

OPAL is an ongoing open-source project which is already keeping hundreds of policy agents updated in real-time. You can join OPAL’s Slack community to chat with other devs who use OPAL for their projects, contribute to the open-source project, or follow OPAL on Twitter for the latest news and updates.

How to build authorization like Netflix with Open Source? was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before we start breaking the decision process of picking an authorization service, let’s, just for the sake of clarity, define what it is first –

What is Authorization as a Service

Authorization as a service (or better-named ‘Permissions as a Service’ to differentiate from ‘Authentication as a Service’) enables software developers to build applications that can request and receive permissions to access certain resources or perform certain actions on behalf of an end-user. These permissions are typically granted by the end users themselves.

By using a ‘Permissions as a Service’ provider, developers can focus on building their application’s core functionality rather than spending time and resources building and maintaining their own authorization and permission management systems.

Don’t Confuse with Authentication

Every developer, when presented with the question: “Do you know the difference between Authentication and Authorization”? Will undoubtedly reply: “Of course!” In reality, you’d be surprised how often they confuse the two.

Authorization as a service really (and I mean really) shouldn’t be confused with authentication as a service; which deals with verifying identities (as opposed to checking what they can do or not, once verified).

Some authentication services come with role and/or user management — making you think they include permissions, but these always just translate to claims in your JWT, which still require you to write code to enforce alongside more data points (e.g., billing status, anomaly detection); or worse — they translate into a simple API you query in their cloud — both killing your application’s performance with latency and limiting your ability to upgrade to more complex policies (e.g., moving from RBAC to ABAC).

Why Should You Use an Authorization Service

Building permissions as a service is at a critical junction of requiring advanced knowledge in cryptography, cybersecurity, the intricacies of policy models (e.g., RBAC, ABAC), and high-performance real-time distributed systems — all while not being unique to any product.

Authorization requirements have a tendency to grow exponentially with the application; starting easy at first (e.g., Admin / Not admin — hardcoded into the app) but quickly becoming complex with the various requirements from customers, security, compliance, and 3rd party integrations. With new requirements often leading to a full refactor every 3–6 months.

The bottom line is that you should use an authorization service to avoid wasting time reinventing the wheel and avoid making mistakes that can easily translate into vulnerabilities or critical performance issues.

The Key Factors for Choosing an Authorization Service

Compatibility:

Let’s face it, you probably already have something in place (even if it’s just a single DB table with a user role column). So make sure that the solution is compatible with your existing systems and infrastructure. This includes compatibility with your cloud environment, programming language, and data sources.

In addition, you should make sure that the transition to the new solution can be a gradual and fast one (or at least gradual). Gradual means the ability to run the new solution side by side with your existing one and test it behaves as you expect.

Best Practices:

Anyone can build a service that just returns a list of roles (and many developers do at some point or another in their careers) — but without the best practices baked into the solution, maintaining it, and ultimately refactoring or replacing it would be painstaking and time-consuming.

Policy as Code, event-driven updates, Gitops, control-plane back office, and customer-facing experiences are some of the best practices you will need and really shouldn’t compromise on.

Latency and locality:

The average microservice-based application triggers three authorization queries per request. If each takes more than 50–100ms, the performance of your application is basically dead before it even starts to handle its own core logic. Latency across cloud services is basically unavoidable (the service provider might be able to reduce it somewhat but not remove it altogether — especially under heavy workload scenarios).
Hence it is best to avoid authorization services that provide only remote querying options and that haven’t taken latency into account.

Policy Model Support:

As your application evolves to meet new demands, so will your authorization layer — so while everyone often starts with Admin/Not-admin, RBAC, ABAC, ReBAC, and variants of them are most likely in your app’s future. Different solutions would support different models and varying levels.

For example, Google-Zanzibar-inspired solutions are a great way to implement ReBAC but are often impossible to implement or impractical for ABAC.

Scalability:

Consider the scalability of the solution. If you expect your user base to grow significantly over time, you’ll want a solution that can handle the increased load and complexity (e.g., of policy or application structure).

Security and compliance:

Security is always an important consideration, especially regarding access control. When picking a service provider, you should aim for one that has cybersecurity as part of its DNA, building with security by design (and not adding it as layers later). You should ask your provider how they intend to work with your sensitive data for authorization without increasing your attack surface and risk of data leakage.

Ease of use:

Choose a solution that is easy to use and set up. This will make it easier for you to manage permissions and reduce the risk of errors. Remember that this tool isn’t going to be just for your own use — your fellow stakeholders (e.g., product managers, security teams, compliance, support, sales, …) will need to work with this as well. The better you can delegate usage to them, the less of a bottleneck you’d have to be. Prefer solutions that provide user interfaces, as opposed to just APIs and infrastructure.

Support:

Make sure the solution has good customer support in case you have any issues or questions.
I’d recommend taking their support for a spin, asking a question in the solutions community or support forum, seeing how quickly you get a response; or at least glance at how quickly other people’s questions get answered.

TL;DR

Authorization as a Service, also known as permissions as a service, enables developers to build applications that can securely gate access to certain resources or perform certain actions on behalf of an end-user. Using an authorization service allows developers to focus on building their core application functionality rather than spending time and resources building and maintaining infrastructure, APIs, and human interfaces that aren’t unique to any application. When choosing an authorization service, compatibility with existing systems and infrastructure, best practices, latency and locality, scalability, and cost should all be considered. It is important to use an authorization service to avoid reinventing the wheel and to avoid mistakes that can lead to vulnerabilities or performance issues.

How to choose an Authorization Service? was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Access control is a must in almost any application, yet most developers end up building and rebuilding it repeatedly — forced to refactor with new customer, product, or security demands coming in.

Why? Usually, they make one or more of four crucial mistakes that prevent them from having a flexible access control layer that can be upgraded without having to rebuild it every time a new product demand comes in.

Before we dive into these, we first need to acknowledge that Permissions are hard, and they’re becoming harder as the world moves into cloud-native ecosystems and microservices. Let’s try and understand why -

What makes permissions complex?

Moving from monoliths to distributed microservices

Back when applications were structured as monoliths, the decision-making process of who connects to what within an application could be baked into one place, usually by using a specific framework such as Spring, Django, or Python.

When working with distributed microservices, especially in a polyglot structure, these solutions are no longer applicable, so you end up having to sprinkle a bit of access control into every little microservice and component you’re building. This creates an issue where we struggle to upgrade, add capabilities and monitor the code overall as it is replicated between different microservices.

Connecting to 3rd party services

It’s not just about the services you provide anymore: The ability to connect your application to 3rd party services (Like authentication, billing, analytics, machine learning agents, or databases) has become a crucial aspect of building any application — this requires us to manage access control for elements outside our own cloud.

New, complex permission models

The policies, rules, and models we want to enforce permissions with are also becoming more complex. Applications often start with an Admin / Non-Admin model and quickly move to increasingly complex models such as RBAC, ReBAC, and ABAC. Our expectations for applications and the different ways we can collaborate within them have never been higher, creating a need for ever-evolving complex policies.

Security and Compliance

If back in the day, doing SOC 2, ISO, or meeting GDPR or CCPA standards was out of the ordinary, today, these standards are common for basically any B2B (and often B2C) application.

These standards, along with HIPPA and PCI, all have lots of requirements related to having checks and balances for your application’s access control.

We can significantly reduce the amount of hardship we need to go through to meet compliance standards by implementing good access control. Having a feature like auditing, combined with visibility into your access control level, which you can share with your auditors, security, and compliance, is expected from almost any solution being built — maybe not on day one, but probably quickly down the road.

If that’s not enough, there’s a lot of security friction and vulnerabilities surfacing from challenges in building access control. It’s no surprise that broken access control is the top A1 item on OWASP’s list of vulnerability sources, with the highest occurrence across all the surveys.

Permissions are not only a problem in how we manage and build things, but it is also creating security issues in our production, which we may face as security incidents.

Now that we understand the depth of the problem, let’s jump into the common anti-patterns that people often end up implementing into the access control that they’re building, creating security vulnerabilities.

The Antipatterns

1. Mixing ‘Auths’ — Authentication VS Authorization

Mixing up authentication and authorization is probably the most common pitfall out there. Despite both belonging to the IAM space, the two are very different. In short — the IAM space consists of three parts: Identity Management (IM), Authentication (AuthN), and Authorization (AuthZ).

• Identity management solutions like OKTA and Azure Active Directory are used on the organization side, defining different organizational identities and their relationships.
• Authentication is done on the product side, where you verify identities before allowing them into the product (Log in).
• Authorization is the layer that lets us enforce and check permissions within the product.

These three steps trickle down into one another, but we must understand their differences.

Role translation

One source of confusion between identity management, authentication, and authorization stems from their use of Roles. The concept of Roles exists through the IAM space, but the meaning varies in each part.

Identity Management Roles indicate a role within an organization (Like “Head of Marketing” or “Member of Security Team”). These roles are drastically different from those used on the application level (Like “Admin,” “Reader,” or “Viewer”). Translating IM organizational roles into application-level Authorization roles is not always a straightforward process, but it is an issue that clearly needs to be addressed.

The result of this translation (For example — Deciding that our Head of marketing, who is part of the marketing team, should have an editor role for the CMS) should be saved as part of the JSON web token (JWT) produced by the authentication layer.

What else should JWTs be used for? Glad you asked.

Using JWTs

Basically, the translation of the IM role into an authorization layer role (Or — the translation from an organizational role into an application level role) should be the only thing included in the JWTs.

Developers often tend to overuse JWTs, sometimes going as far as storing all the routes that a user should access within them. That is a bad idea for several reasons:

• Mixing the authentication and authorization layers messes up our code.
• Changing roles requires the user to log out and log in again, which can hinder the user experience and overall application performance.
• As the JWT is sent for every request with a RESTful API, GraphQL, or any other HTTP-based solution, creating a bloated JWT would significantly slow down the application’s performance.
• There is a limit to how much data can be stored within a JWT. If we keep adding more rules, we will eventually run out of storage space.

The best way to avoid this is to have the JWT only include the claims and scopes for the user’s identity and their relationship within the organization and keep all other authorization-related information in a separate layer within the application.

Speaking of creating a separate layer for authorization, the next common mistake devs make is mixing up application logic with authorization logic.

2. Mixing up App-logic and Authorization

When building an application, we have the logic of what the application is supposed to do, and we have the logic for who is allowed to perform which actions within it.

The combination of these two logic sets could easily result in us having spaghetti code composed of a mix of unrelated elements. If we will need to upgrade the application or the authorization layer (Which is rather likely to happen at some point), we’ll end up having to cherry-pick different elements of code, trying to figure out which are application related and which are authorization related.

When these two logic sets are combined, they inevitably grow organically and become increasingly cumbersome, turning any future effort of separating, editing, updating, or upgrading them into a nightmare.

There’s also an issue of performance here — Let’s say our application checks a user’s payment status to approve or deny access to certain features. Checking this every time as part of the application flow could significantly hinder the application’s performance.

A much better way to approach this issue is to decouple our policy from our code. This way, the authorization layer can run in the background and monitor the user’s payment status. Whenever we want to check that status, it will already be available in the authorization layer, eliminating the need to fetch it every time.

3. Mixing up your Access control layers

Every application requires multiple layers of access control -

• Physical access control, like having locks on our doors and windows.
• Network level access control, like firewalls, VPNs, and zero trust networks.
• Infrastructure level access control, like limitations on which services can talk to each other.
• And lastly, application level access control.

Each of these layers has different demands, requirements, policies, and models. Ideally, we would have a unified interface/back-office where we can view, manage and audit all these different layers. The ability to manage them as code would be even better, as it allows us to manage and run tests on them as part of our source control.

The main mistake we often see developers making in this aspect is combining their application-level access control with a tool that was built to manage infrastructure access control, like AWS IAM.

Initially, this might look like a great idea — AWS IAM is a very powerful tool that can map many things into objects, which is why engineers use it to map their application-level access control. So why is this not a good idea? Let’s look at a specific example.

We often encounter engineers mapping their application-level access control using SS3 buckets in AWS. Because their data is stored in a bucket anyway, they feel they might as well use the access control for the bucket for the application itself. Although this may sound great on the surface, it’s easy to see when things start to go wrong -

The moment you’ll want to move to a different cloud or even a different storage layer within the same cloud, there’s a good chance you won’t want to use the buckets anymore — you’ll want to use RDS, Redshift, or Snowflake. Just because the requirements for your application have changed, you will have to completely refactor your access control because it was coupled into that specific cloud component infrastructure.

It can also be a major problem to rely too much on how things are built for these specific components. A lot of people rely on the way you configure the API gateway to do enforcements for your application. Sadly, AWS encourages you to put routes inside the JWT — a practice devs end up adopting as something they can take into production in scale and end up regretting in the long run.

Ultimately, it’s important to remember that different access layers have different needs. If we ignore these needs, we might regret it later and end up having to refactor large parts of our applications.

4. Thinking that you can solve it once and for all

The last major mistake developers tend to make when thinking about permission building is more of a conceptual one — Thinking they can solve it once and for all.

Many young companies fall for this misconception and end up rebuilding their access control over and over again instead of developing crucial new features in the application itself. The worst thing about that is that every time they do it, they think this time will be the last. In reality — if you follow even just some of the anti-patterns we described here, there’s a good chance that every time a new requirement comes in from a customer, partner, security, or compliance, you just might have to throw out everything you’ve built and start from scratch.

The only way to avoid this scenario is to plan for it. Building an ever-growing, ever-developing application, you have to assume that you will have to evolve your authorization layer to support more policies and complex roles. You have to assume you will move from RBAC to ABAC or other even more complicated models and provide interfaces on top of them.

This doesn’t mean you should try and build a perfect, future-proof permission management system from day one — especially if you are working in a startup company. You’ll just never finish. Instead, focus on setting the right groundwork — if you plan ahead and avoid the mistakes we discussed in this post, you will be able to upgrade your permission layer with much more flexibility — instead of having to rebuild it from scratch every three to six months.

Most companies go through the same steps — they initially build good schemas for their data layers and authorizations, but gradually, as they move forward, these schemas stop working, and they start facing performance issues. The only way to avoid this is to decouple your authorization layer from your application’s logic and be ready to update it gradually as demands come in.

Let’s sum everything up -

Whether it’s the move to distributed microservices from monoliths, the requirement to integrate 3rd party services into your application, the necessity of using complex permission models, or the rise of security and compliance requirements, permissions have become more complex than ever.

All of these changes require us to adopt new best practices and avoid common mistakes developers make when thinking about authorization:

Mixing Authentication and Authorization, especially when it comes to the somewhat confusing translation of organizational roles into application level ones and the correct usage of JWTs, mixing up application logic with authorization logic, using tools designed for infrastructure access control (like AWS IAM) to manage application level access control, and thinking that we can solve our authorization problems once and for all on day one.

Most importantly, it’s important to understand that developing a good authorization layer in a constantly changing application requires planning ahead and building a flexible solution that can be upgraded without having to rebuild it every time a new product demand comes in.

Building authorization? Got questions? Come talk to hundreds of developers working on solving their IAM challenges in our Slack community!

The four mistakes you make building permissions was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

IAM Abuse is a real deal, and cases like “Tesla Hackers Hijacked Amazon Cloud Account to Mine Cryptocurrency” can be life-threatening for every company using a cloud provider. Taking care of this aspect of cloud account management can be the difference between successfully managing your cloud resources and losing them all.

As a DevOps Engineer, I personally began learning about AWS Identity and Access Management (IAM) solutions as my first step within the AWS space in general. I’ve been hearing about the pain of configuring IAM the right way for years now.

What’s causing this pain?

That’s a bit tricky. There are two sides to the IAM “coin”:

On the one hand, looser IAM policies make it easier for developers to do their jobs, but they also pose a serious security risk. On the other hand, while solving the security risks, overly strict IAM rules will make things difficult for developers on a daily basis.

A careful balance needs to be struck between enabling a good experience for the development team and minimizing security risks. This fine balance is unique for every company, and finding it and adjusting it over time is the key.

In this post, I aim to help you better understand this balance and set down a few best practices for achieving it. To do so, I’ll include some core scenarios of using Roles, monitoring role usage, how to use OIDC (OpenID Connect) with your Kubernetes or Github, as well as a few other tips.

Before we dive in, let’s go over some of the basics of managing IAM on AWS.

AWS IAM: A basic introduction

With AWS’s Identity and Access Management, we, the developers (and users), can decide what resources a user, a group, or a role can view or change. In other words: Who can perform what Action on Which Resource? We’ll start with talking about the smallest building block of the IAM — AWS Policies:

Policy Structure

Policy JSON documents are comprised of the following elements:

Effect — Allow or Deny access to the resource is decided by Effect (Allow/Deny)

Action — A set of service-specific parameters (like “iam: CreateUser”).

Resource — Resource names (like “arn:aws:s3:::conf-* “)

Condition (Optional) — Grant conditions (like “aws: RequestedRegion”: “ap-south-1”)

Here’s an example of a JSON policy document:

{
   Version: "2012-10-17",
   Statement: [
       {
           Effect: "Allow",
           Action: [
               "route53:ChangeResourceRecordSets"
           ],
           Resource: [
               "arn:aws:route53:::hostedzone/*"
           ]
       },
       {
           Effect: "Allow",
           Action: [
               "route53:ListHostedZones",
               "route53:ListResourceRecordSets"
           ],
           Resource: [
               "arn:aws:route53:::hostedzone/*"
           ]
       }
   ]
}

Note: This policy allows changing record sets for all Route53 zones; however, “create” permissions do not entitle the user to “read” or “list,” so I added the ability to list all hosted zones and record sets to the policy.

Policy Attachment

Each policy can be attached to a user, a group, or a role.

Policies attached to users and groups are quite basic and easy to understand — each AWS user or a group can have many policies (It’s also helpful to note that policies are reusable!), while Groups are simply a bunch of users that will share the same policies.

The same goes for roles: A role can have many policies attached to it. What makes roles a bit trickier is that unlike users and groups, which can be accessed via basic authentication or tokens, roles only work with a role assumption mechanism.

AWS IAM: 5 Best Practices

As mentioned before, achieving a balance between flexibility and security when managing your IAM solution is crucial in keeping our application secure while enabling infrastructure for our engineers. This can, however, be quite challenging.

Let’s dig in with some best practices for leveraging the power of IAM and Roles in particular.

1. Assuming Roles — Avoiding Premature Privilege Escalations

Roles are a critical part of AWS IAM because they allow us to manage permissions between services and resources and automate actions in AWS.

Roles basically function as a policy administration layer, as many policies can be attached to each role, and roles are assumed by various entities. This extra layer allows us to control and manage our IAM much more efficiently using the tools which AWS IAM provides us:

“Trust Relationship” policies allow us to secure who can use the role, CloudTrail allows us to monitor who’s assuming which role, and OIDC lets us allow 3rd party services delegate AWS permissions. In the next following segments, we will dive into how to use these tools to enhance our organization’s IAM rules and make sure they are secure and flexible.

In the absence of roles as an extra administrative layer for managing policies, premature privilege and permission escalations are likely to occur. These can manifest as unmanaged policies and users, unmanaged 3rd party services policies, and many more potentially harmful administrative gaps, resulting in serious security breaches for your organization.

When talking about assuming roles, we will be using the AWS Security Token Service (STS), which is a web service that enables you to request temporary limited-privilege credentials for AWS IAM.

By using the AWS STS, we can invoke the AssumeRole action that returns a set of temporary security credentials that may be used to access AWS resources you would not normally have access to. To simplify that, we can say that this action places you ‘in the guise’ of the role you choose to assume. So if I choose to “assume” my new “ExampleRole,” the policies contained in “ExampleRole” will simply be delegated to me.

In order to use the role you created, you must use the STS API to “assume” it.

Fortunately, most of the 3rd party services like Github, K8s, Terraform, and many more offer an easy way to assume roles, thus making the usage of roles much more flexible and convenient, which is essential when talking about developer experience.

2. Using Roles in Real-Life Scenarios

When roles should be used is a tricky question. We can better demonstrate the usage of roles by explaining and understanding Why roles should be used in the first place. There are several explanations to why we should use roles — we’ll divide them into 4 parts that will also include examples of using roles in the real world.

Easier Policy Management, Auditing, and Tracking

⁠Let’s say, for example, that we need to share the ability to delete EC2 instances. We can easily create a proper policy and attach it to a user, or even better, to a group. In this made-up scenario, we’ll suppose the demand for deleting EC2 instances is very common.

The thing is, deleting EC2 instances is a very sensitive permission to have. We can’t just give it to any user. So how can we solve this problem?

We can create a role called “EC2DeleteRole” (attached with the policy of deleting EC2 instances), and make sure that having this role is the only way you can get this permission.

We, the IAM administrators, will be able to track and manage our identities’ permissions much more effectively by assigning this permission to a specific role. Imagine a situation where we want to remove the EC2 instance ‘delete policy’ from every identity on our AWS account. Rather than going through every identity and deleting this policy, we can simply do it by deleting the “EC2DeleteRole” we created earlier.

Roles are basically a toolbox for managing policies in a very flexible way, so don’t be afraid to use them!

De-Risking Automations and 3rd party services

Occasionally, we will need to delegate permissions to third-party services or automation to operate on AWS. There are high risks associated with this (Such as supply-chain attacks), which is why we must ensure that all the components of our infrastructure are highly secure so that an attacker cannot gain access to our infrastructure through a weak or unsecured component.

When it comes to delegating permissions for automation or third-party services, the only available options are providing authentication tokens and passwords per dedicated user or using Roles.

The option of sharing authentication tokens and passwords is the easiest to implement; just throw in your password as a variable, and that’s it. Sadly this can expose the organization to a lot of maintenance issues and security risks, as passwords can be accidentally shared or accessed by an unwanted threat.

This is where the thin line between flexible and secured IAM is crossed, and we must be sure that both are well implemented without compromise.

To achieve this, the best option is to use roles!

We can easily provide our 3rd party automation or service a role ARN to assume in order to get the permissions it needs. The same goes for managing permissions for infrastructure-as-code tools such as Terraform, Pulumi, and Terragrunt and even more robust systems such as Kubernetes or Hashicorp Nomad.

This can be achieved using the OpenID provider, which we will discuss further.

Delegating permissions between accounts -

Say our organization has several AWS accounts — one account for each SDLC environment (Development, staging, and production, for example), and for some reason, we are asked to give a service that is located in the staging account, the ability to reach an S3 bucket on our development AWS account.

Roles enable us to accomplish that, as roles can be assumed between accounts.

When creating a new role, we can choose that the “trusted entity” of this role will be a different AWS account; this way, the role will be assumable by a different account.

There is only one other option, which is to create a dedicated user and pass the password as a raw variable, which is highly insecure.

Service Roles -

Many AWS services require you to use roles in order to control access. A role that a service assumes to perform actions is called a Service Role. When a role serves a specialized purpose for a service, it can be categorized as a service role for EC2 instances or a service-linked role.

It’s useful to clearly distinguish between internal and external services, as each one of them will require a different set of roles. For example, AWS core services such as Amazon Data Lifecycle Manager will require a specific set of policies in order to operate properly, so we would keep this “Service Role” static as we don’t want to break the service’s operations.

On the contrary, managing roles for external services such as Kubernetes will require much more maintenance and monitoring from our side, as these kinds of roles are much more dynamic in their needs, which may lead to security issues and potential human error.

Consider marking the external services differently than the internal ones in your cloud architectural design, then design each of them separately. This will help you better understand which roles require more attention, as external service roles may be unsafe for our organization in some cases.

3. Monitoring role usage using AWS CloudTrail

When a large number of roles accumulates, it can be difficult to manage them effectively. In this case, AWS CloudTrail can come in handy.

Imagine a situation where a user gets access to a role that you don’t even remember exists or a scenario when multiple roles have the same policies. IAM and effective permissions on AWS should not be managed that way.

In order to avoid such scenarios (and worse ones), we can use AWS CloudTrail.

With this great AWS service, we can monitor and capture the activity of our organization’s users and the API usage across AWS regions and accounts on a single centralized interface.

AWS CloudTrail gives a lot of information about everything related to auditing the cloud activity and monitoring this data, and with that, we can watch for any unwanted activity of role assumptions and much more.

CloudTrail could be useful when monitoring who is reading secrets from our AWS Secret Manager. There’s no doubt that reading secrets should be a well-monitored action on our account since we want to ensure that only very specific users and groups can read secrets.

We can monitor who’s reading which secret, which role the identity is assuming, its IP, the event time, and much more.

4. Restrict role assumption with Trust Relationship policies

Should all roles be available to everyone? Clearly not. Roles are important entities that should always be kept safe from potential threats. Every role has a special policy called a “trust relationship policy”. This policy looks very similar to any other, and we can specify who can assume the role using it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

In the above example, we attached a trust-relationship policy to our role that specifies that only the root user of the “111122223333” AWS account can assume this role, as indicated in the Action statement: “sts:AssumeRole”.

Trust Relationship policies are like whitelists or blacklists for roles. Imagine a situation where we create a role that has the permission to delete EC2, and everyone in the organization can assume this role. Obviously, this is not a good idea, so we must specify which entities are allowed to use this role and which ones aren’t.

5. Streamlining permissions with 3rd party entities: OpenID Connect

What is OpenID Connect (OIDC)?

OIDC is an open authentication protocol that profiles and extends OAuth 2.0 to add an identity layer. It allows clients to confirm an end user’s identity using authentication by an identity management server.

The OIDC standard is used by many well-known services to delegate access and authentication securely. Luckily for us, AWS IAM supports OIDC as a valid identity provider.

As we mentioned previously, flexibility is extremely important when talking about IAM, as we want to ensure that our engineers are able to have a frictionless working experience with the infrastructure. Fortunately, using OIDC as an identity provider for AWS makes the authentication for AWS much more flexible and secure, as it allows us to integrate our 3rd party services with AWS IAM seamlessly.

In my day-to-day usage, I use the OIDC identity provider for Github Actions. This gives Github Actions the ability to interact with AWS without any passwords or tokens.

Using OIDC with Kubernetes is also great, as it helps integrate K8s’ service accounts with AWS IAM. For example, using OIDC allows us to give our Kubernetes service accounts the ability to assume roles from AWS.

My favorite live example is configuring ExternalDNS in EKS (Elastic Kubernetes Service powered by AWS) to work with our Route53 DNS records using OIDC integration. In short, ExternalDNS synchronizes exposed Kubernetes Services and Ingresses with DNS providers.

AWS provides the OpenID Connect Provider Issuer out-of-the-box when creating an EKS cluster, so in order to integrate our Kubernetes cluster with the OIDC, we just need to create the OIDC provider, and the following resources:

1. Kubernetes Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-dns
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT-ID:role/IAM-SERVICE-ROLE-NAME

2. AWS Role with the following trust relationship

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${OIDC_PROVIDER}:aud": "sts.amazonaws.com",
          "${OIDC_PROVIDER}:sub": "system:serviceaccount:my-namespace:my-service-account"
        }
      }
    }
  ]
}

You can check out more information on Creating an IAM role and policy for your Kubernetes service account; read here.

Not using OIDC may require engineers to use raw passwords and tokens, which are extremely insecure and inflexible, and mostly add a lot of friction to the process.

Good IAM is a must

Managing IAM for our organization can be a big deal; as we showed above, on the one hand, loose IAM can be a real danger to the whole company and can expose the company to many risks, but on the other hand, IAM policies that are too strict can make our engineer’s lives much harder.

Following the mentioned best practices, such as assuming roles, using AWS CloudTrail to monitor users and API activity, restricting role assumptions using trust relationship policies, and using OpenID Connect as a way to integrate your 3rd parties to AWS, you can make your IAM administration and operations much easier, flexible, and secure. In this age of cloud computing, that’s a must!

Want to discuss more policy permission models? — hit me up on Permit’s Slack community.

5 Ways to Improve your AWS IAM Roles and Policies was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Multitenancy

At its core, multi-tenancy allows every part of the service (i.e., every microservice) to cater to multiple customers without deploying separate instances for each.

For a SaaS solution to scale affordably, meet customer demands, and be elastic in doing so (i.e., cost-effective in cloud resources), it has to support multi-tenancy.

A multitenant architecture provides many great and often essential features:

• Allowing the application to serve multiple customers at once while sharing the underlying infrastructure and services
• Secure and compliant access separation
• Load balancing and scaling

The two layers of Multitenancy

At the end of the day, multi-tenancy is easy once you understand it, and it basically requires only two things: Application level access control and managing data schemas.

Let’s break it down into two planes:

• The data plane is all about how you transmit, store and manage the siloed data (i.e., How the underlying infra avoids mixing up the data of different tenants). Multi-tenancy for the data plane is often implemented as partitions on the data layers — e.g., separate partitions, tables, columns, identifiers, and/or labels on the data storage schema (how you save it in the database) and topics (e.g., Kafka topics), tags, domains, sockets, and/or ports, for the data at transit.

• The application plane is about how you silo context and access within the logical layer, i.e., have the same code work for different tenants. Authorization is the component within the application plane implementing multi-tenancy.

Implementing multi-tenancy

An authorization layer is the fastest and most reliable way to upgrade from a single-tenant application to a multi-tenant one safely. In addition, the authorization layer can implement separation without requiring changes to the services themselves by applying a policy across all relevant services.

Choosing the right policy model can simplify this transition even further, with classic models like RBAC + Tenancy, ReBAC + Hierarchy (tenants becoming root-level relationships), or plain vanilla ABAC (with tenancy as an attribute).

The great thing is we don’t need to implement multi-tenancy authorization on our own, and instead can enjoy ready-made open-source tools and services.

Implementing multi-tenancy with OPA + OPAL (Open-Source)

Open source is a great option to start implementing your authorization layer for multi-tenancy. While there are multiple options, Open Policy Agent (OPA) is among the most promising.
OPA acts as an authorization microservice that we can add to our application and use to enforce access with rules written in its proprietary Rego language.

Combining OPA with OPAL (Open Policy Administration Layer) enables us to manage our authorization layer in scale, using Pub/Sub topics to keep our agents up to date with policy (Rego code) and data (JSON documents). The topics, for example, can be our tenant names or IDs, allowing us to sync our agents with changes per tenant.

Implementing multi-tenancy with Permit.io (Service)

App authorization solutions (Such as Permit.io 😇 ) solve the application aspect out of the box and layer easily on-top of the data plane by providing (or correlating according to) unique identifiers that can be used to partition the data plane.

Permit builds on top of OPA and OPAL, adding management interfaces, including a tenants list, tenant resource management, and per tenant user management.

To sum things up -

Multi-tenancy allows our application to cater to multiple customers without deploying separate instances for each. Multi-tenancy enforcement in gist consists of two planes: data and application. One of the best ways to achieve Multi-tenancy is by creating an authorization layer that can implement separation without requiring changes to the services themselves. Although you can build your own authorization layer, there are also open-source options (Such as OPA + OPAL) and Services (Such as Permit.io) that allow you to implement one in your application — making the critical shift into multi-tenancy more accessible.

Considering multitenancy for your app? Got questions? Join our Slack community and chat with fellow developers building authorization!

How to Implement Multitenancy in Cloud Computing was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Way back in 2013, various devs were either announcing or debating the death of XACML — yet XACML’s goal to promote a common terminology and interoperability between authorization implementations remains valid, and it still serves as a solid base to describe the structure of authorization architectures.

The IAM landscape, authorization included, has evolved drastically in the past couple of years and allowed for new XACML alternatives to be created. This significant shift was a result of the rising demand for increasingly advanced authorization, which was generated by the growing complexity of applications and their migration to microservices and cloud-native structures. With advancements in technology, the emergence of shift-left and low/no-code developers, and the need for event-driven dynamic authorization — a replacement for XACML had to evolve.

One such XACML alternative is OPA + OPAL. Open Policy Agent (OPA) is an open-source project created as a general-purpose policy engine to serve any policy enforcement requirements that unifies policy enforcement across the stack without being dependent on implementation details. It can be used with any language and network protocol, supports any data type, and evaluates and returns answers quickly. OPA’s policy rules are written in Rego — a high-level declarative (Datalog-like) language. You can find a more detailed introduction to OPA here. It’s important to note that OPA itself only provides an alternative to XACML’s PDP (More on that further). OPA is enhanced by OPAL (Open Policy Administration Layer) — another open-source solution that allows you to easily keep your authorization layer up-to-date in real-time. More information about the project is available here. The combination of OPA and OPAL provides a solid alternative for XACML.

To better understand this alternative, we’ll compare the traditional XACML architecture authorization flow with the one provided by OPA + OPAL and then discuss the differences. It’s important to note that while being a primarily Attribute-Based Access Control (ABAC) system XACML can also be used to describe Role-Based Access Control (RBAC) and other models.

A few basic terms to understand the flow:

The architecture of XACML consists of a few different modules that make up the process of making authorization decisions. Let’s take a look at those different parts: PEP — “Policy Enforcement Point”: The PEP intercepts a user’s access to a resource, and either grants or denies access to the resource requested by the user. PEPs don’t make the decisions; they enforce them. PEPs can potentially also adjust requests or their results before passing them through (aka data-filtering). Examples of PEPs are in-code control flow (i.e. “if”), middleware, reverse proxies, and API gateways

PDP — “Policy Decision Point”: The PDP evaluates authorization requests against relevant policies and a data snapshot aggregated from the distributed data layer and makes an authorization decision.

PAP — “Policy Administration Point”: ⁠The PAP is in charge of managing all relevant policies to be used by the PDP.

PIP — “Policy Information Point”: The PIP is any data source (Internal or external) that contains attributes that are relevant for making policy decisions. PRP — “Policy Retrieval Point”: ⁠The PAP is the main source of policies — it stores all relevant policies to be used by the PDP, and is managed by the PAP (In OPA it’s a bundle-server, and in OPAL this is often a Git repository or an HTTP bundle server).

Traditional XACML Architecture

Let’s start by reviewing the architecture of traditional XACML and its authorization flow:

1. Everything starts with a user (or automated entity) interacting with an application. The user sends a request to access and perform an action on any sort of resource within the application. Before being submitted to the application logic, the request passes through the PEP. The PEP is in charge of either granting or denying a user’s request for access to the resource.
2. The PEP translates the user’s request into an XACML authorization request. It is important to note that one user request can trigger multiple authorization queries (as it interacts with multiple resources).
3. To know whether the request should be approved or rejected, the PEP sends the authorization request to the PDP.
4. The PDP makes make authorization decisions based on pre-configured XACML formatted policies.
5. The policies are stored in the PRP and are managed by the PAP.
6. If needed — the PDP queries relevant PIPs per query for any additional relevant information.
7. The PDP reaches a decision (Permit / Deny / etc.) and returns it to the PEP.
8. The user is either granted or denied access to the resource by the PEP, based on the PDP’s decision. ⁠

OPA + OPAL Architecture

While based on similar principles, OPA and OPAL provide a slightly different authorization model with significant benefits:

1. The first step is identical to XACML — the user / automated entity sends a request and it passes through the PEP.
2. The PEP converts the user’s request into queries for the PDP (In this case — OPA).
3. The queries are submitted by the PEP to the PDP (OPA) to know whether the request should be approved or rejected. So far so good — here is where things are a bit different. First of all, OPA stores all relevant policies within its cache. Second — the policies are represented as code (In Rego), unlike XACML where they are represented as configuration (as XML schema).
4. The PAP (In this case — the OPAL Server) serves a dual function. It both functions as a Policy Administration Point and a Policy Information Administration Point. 4.1 As a Policy Administration Point — The OPAL server is in charge of managing all relevant policies and supplying them to OPA, within the PDP. Policies are stored as code in a GIT repository (default option, though others exist), which acts as the PRP. The OPAL Server receives policy updates from the PRP and instructs the OPAL clients to update OPAs’ caches accordingly. Every time a change in a policy happens in GIT, it is pulled by the OPAL Server and pushed into OPA’s cache via the OPAL clients which listen to the server (based on topics) and are located next to the OPA instances. By leveraging GIT and policy as code, OPAL allows us to use Gitops best practices (e.g. tests, code-review, benchmarking) In this manner, OPA always stays up to date with the latest policy changes in real-time without the need for redeployment. 4.2 As a Policy Information Administration Point — the OPAL server informs the OPAL Client within the PDP on changes to data within the PIPs according to selected topics. With the updates to the client, the server sends instructions on how to query the PIPs, and the OPAL Client fetches the data directly from the PIPs (according to the instructions) and updates OPA with the most recent information. As this process is continuous, the information stored in the PDP cache is always up to date with the latest data needed to make access decisions in the most accurate way possible.
5. The PDP (OPA) reaches a decision (Permit / Deny / etc.) and returns it to the PEP.
6. Based on the decision made by the PDP (OPA), the PEP either grants or denies the user’s access to the resource. ⁠

The differences

From the differences in the authorization flow between the traditional XACML and OPA+OPAL, we can note three significant benefits which the latter provides:

1. The OPAL server’s ability to receive updates from GIT (Or any other policy source) keeps OPA up to date with the most recent policies — allowing us to make policy changes on the fly and have them utilized by the PDP with minimal latency. Leveraging policy as code within a GIT repository enables the adoption of configuration as code and Gitops in general.
2. The OPAL server not only manages the policies themselves, but also the PIPs from which additional data is often required to make a policy decision. The OPAL Client constantly listens to changes in relevant PIPs (Internal or external databases) and uses data fetchers to keep OPA’s cache constantly up to date with the latest information needed to reach an authorization decision. Because this is an ongoing process and not done per query, OPA can have all the relevant information in its cache to make policy decisions even if the PIP is not available — preventing the PDP from making the authorization decision.
3. While not evident from the authorization flow which we described, it is important to note that policy in Rego is much more accessible and easier to read/maintain than in XACML. Check out this example: (For a more detailed explanation of this example check out this guide)⁠.

The differences between Traditional XACML and OPA+OPAL highlight the drastic changes in the authorization space that occurred in recent years. OPAL’s ability to receive both data and policy updates in real-time allows for the creation of event-driven dynamic authorization. At the same time, OPA provides the ability to define more complex authorization structures fit for microservices and cloud-native structures, and its policy language Rego is easier to read/maintain and provides accessibility to low/no-code developers. OPAL is a mature open-source project which is already keeping hundreds of policy agents updated in real-time. You can join OPAL’s Slack community to chat with other devs who use OPAL for their projects, contribute to the open-source project, or follow OPAL on Twitter for the latest news and updates.

OPAL + OPA VS XACML was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Launching Permit.io

Throughout our long (~20 years) careers both Asaf (my awesome co-founder) and I found ourselves constantly rebuilding access control for our products.

At my previous company Rookout- We ended up rebuilding access control over five times; at every turn, we were met with unexpected demands for more roles, features, performance, compliance, security, and overall complexity.

As developers who are passionate about developer tools, we knew that things had to change. Authorization, just like billing, authentication, and databases — is not something one should be building from scratch.

We realized this was a unique point in time where multiple events intersected to create the opportunity that is now Permit.io possible. The explosion of microservices combined with the growing maturity of DevSecOps and authentication (with standards like JWTs) have set the stage for the next step in the IAM waterfall — fullstack authorization and permissions.

Fullstack Permissions

As the space evolves, trends, best practices, and open-source standards (e.g. OPA, OPAL) began to emerge. At Permit we adopt and support these, being strong believers in decoupling policy and code. We also understand that it is not only about decoupling the technology — developers and their fellow stakeholders need end-to-end experiences. Access is the most critical experience of any product — and everyone needs to be able to affect and take part in it.

Fullstack permissions mean empowering developers and users, it means adding UI and low-code next to deep-code and APIs, and most importantly it means you can trust us to make authorization work for you, exactly how you want it — and not just throw some APIs your way.

An Interconnected Future

While a major part of our story is about making developers’ life better — we also note that’s just the beginning, as glimpses of the future through companies like Facebook and Google hint at even greater complexities around the corner.
With more and more applications being used by other applications rather than by human users (Think of Apple’s Siri triggering IFFT to turn on your Xiamoi smart light-bulb), and machine learning agents on the rise, it is clear the matrix of access is only getting more complex.

And as more and more things become interconnected more rapidly, only by creating new standards for authorization, and layering artificial intelligence on top, will we be able to keep up with the needed pace.

The beginning of an amazing journey

Today we’re excited to launch Permit.io out of stealth mode, with the support of our amazing investors NFX and Rainfall, as well a long list of angels and advisors — all coming from the developer-tools space.
Our growing team is already supporting a large open-source project and SaaS service- running in the production environments of industry leaders. And is eager to bring permissions to support the future of software and the internet as an interconnected whole.

To read more about our vision for the future check out the Permit.io blog

Permitting an Interconnected Future was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cloud-native / microservice-based products are complex, and so is building access-control and managing permissions for these products — it’s only getting worse by the pull request. Most developers end up building authorization or access-control for their products multiple times — forced to refactor with new customer, product, or security demands coming in. To make our lives a little easier, let’s go over the unique challenges that building cloud-native permissions poses before us, and cover the five best-practices for building them that can save you a lot of hassle.

Things have changed

We used to build authorization by using monolithic frameworks like Django or Spring that came with authorization or access-control baked-in, but these are no longer applicable when we create applications in the cloud-native space. There are a few reasons for that — Firstly, applications themselves are no longer monoliths — they’re based on microservices and are becoming highly distributed. This becomes even more critical when you need to incorporate devices or instances that are deployed at the edge, which often need access-control too. Second, cloud-native applications tend to require integration of third-party services (Such as billing, authentication, databases, analytics, etc.) and the ability to control access to them in addition to your own application’s microservices. Third, more dynamic and distributed applications require us to use a bunch of different authorization models (e.g. RBAC, ReBAC, ABAC), that are based on multiple data sources, and increasingly complex rules. Lastly, security, privacy, and compliance demands are also rising (in the face of increasingly complex cyber threats) and becoming really complex. We find ourselves not only managing who should access the data but also how it is propagated between different services.

The reality of modern authorization

All of these new needs require us to adopt a different mindset when thinking about authorization:

• Authorization can no longer come as an afterthought — we have to plan it in advance.
• Authorization is an ongoing endeavor — not something you solve once. It’s got to keep evolving along with your product.
• Authorization is key in a customer’s experience — as it affects how users connect and invite others to the product. They won’t like it if it’s bad.
• Authorization is connected to the bigger space of IAM

The 5 best practices

To handle all of these changes, we want to share five of the best practices that will aid you in building cloud-native permissions — and leave you time to actually develop features, rather instead of just running around permissions all day 👍

Decoupling policy and code:

One of the most important and recently popular practices in building cloud-native permissions is decoupling of policy and code. Having the code of the authorization layer mixed in with the application code itself can be very problematic. Most importantly, it creates a situation where we struggle to upgrade, add capabilities and monitor the code overall as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop. This can be avoided by decoupling our policy from our code by (ideally) creating a separate microservice for authorization, that will be used by the other services in order to fulfill their authorization needs. Open-source policy/permissions engines such as OpenPolicyAgent (OPA) or SpiceDB for example allow us to manage authorization in a separate service.

Being event-driven:

We want the application that we are building to be dynamic. Applications often utilize abilities such as user invites, role assignment, or the usage of 3rd party data sources — all of which require to be managed in a real-time fashion. Without it, our ability to make authorization decisions will be significantly reduced. This requires us to design our authorization layer to be event-driven**. We want to create a reality where every time an event that affects authorization happens, it is immediately put through the system to make sure the authorization layer learns about it and remains in sync with the application and any relevant 3rd party data service. Ideally, to achieve this we’d decouple the authorization data from the application data (as not all the data that is relevant for the application is relevant for authorization and vice versa), creating a lean model in our authorization layer and then keeping it in sync with our application and additional sources through real-time events. OPAL (Open Policy Administration Layer), for example, is an open-source project that enables making OPA event-driven. This allows you to respond to policy and data changes, push live updates to your agents, and bring open-policy up to the speed needed by live applications.

Backoffice for stakeholders:

The authorization layer is part of the product itself, and in product-focused companies, there are various stakeholders that need to be able to connect to the access-control experience. These include (alongside developers) dev-ops, product managers, security, compliance, sales, marketing, etc. While building the authorization layer we want to provide controls and interfaces to these various stakeholders through a back-office. This requires us to consider what different stakeholders would need from the access-control interface to our product from day one — that should keep everyone happy.

Interfaces for customers:

In a similar fashion to the stakeholder’s requirements, we also need to think of our end-users/customers. Authorization is not only relevant in managing the product, but also for the product’s end-user. If, for example, users require access to their own audit logs (Something almost every B2B application user would ask) they should be able to see what they have done within the product with ease. Recognizing this need in advance calls for building the authorization layer in a way that enables it to latch on to different interfaces that cater to the needs of the end-users. The list of possible interfaces here is extremely long (and you can probably name a dozen you’ve seen in multiple products). Permit.io ,which, empowers developers to bake in permissions and access-control into any product, provides many of these interfaces.

GitOps:

So we’ve created a separate microservice to manage permissions, and we are able to deliver updates to it in an event-driven fashion. Now, how do we get around to managing those changes, applying versions, applying various checks and balances, and making sure that the code and data for the microservices comply with our demands and requirements? The answer is GitOps. Using GitOps allows us to create a pull request for every version change. Then, as our developers are updating the product and its access-control, they can push a new commit with new code, have those go through the necessary tests and checks, and apply them to the authorization layer.

The future of permissions

With complexity on the rise and a constant stream of customer and security demands, building your product’s access-control in a way that will be ready for the future, and won’t require heavy refactors or rewrites is critical. Creating a separate microservice for authorization, designing it to be event-driven, providing controls and interfaces to various stakeholders and customers, and using GitOps allows us to create a product that is as ‘Future proof’ as possible for authorization, and prevents us from having to rebuild our authorization layer over and over (and over) again — no matter the requirements.

Want to learn more? Check out this video:

5 best practices for building cloud-native permissions was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

The landscape of authorization has changed drastically in the last few years — Today’s applications require complex authorization systems and call for well-designed, adaptive solutions. In this post we will try to answer what changed, both in terms of the challenges and the solutions, and how we can adapt to these changes.

But first, before we dive into this — let’s establish the space that we’re going to be discussing:

The IAM landscape

IAM (Identity Access Management) is composed of three separate parts: Identity management, Authentication (AuthN), and Authorization (AuthZ).

Identity management

⁠⁠Identity management is about being able to tell who’s part of your organization, what attributes they have, and which departments they belong to. This allows you to create identities that can be aggregated and managed in a unified interface.

Authentication

⁠⁠Authentication is all about verifying the identity of the person connecting to your product. These are designated to monitor who has access to the product itself.

Authorization

⁠⁠Once a user has logged in to the product, authorization handles deciding who can do what and in what context within the product.

As you can see, each stage relies on information gathered from the previous one. ⁠A more detailed introduction to the IAM waterfall can be found here.

Building (and re-building) authorization

Up until recently, developers have mostly been building authorization by themselves from scratch. As a developer, you might think -

“Ok, so I’ll start off with two types of users: Admin, and non-admin, and make decisions based on this distinction”.

Then, a user comes in and asks you to create an editor role.
⁠So you rebuild your authorization system to allow an editor role.

Later, stakeholders from your company ask you for access to audit logs, and the ability to monitor them on their side.
So you rebuild your authorization system to allow that as well.

Then sales approach you and ask you to create an impersonation tool that allows them to see the system from a different perspective.
And you rebuild again.

Another stakeholder asks you for their own back-office that will allow them to manage new users they onboard into the system.

You see where we’re going with this.

As your product evolves, building authorization yourself requires you to keep rebuilding it time after time in order to adapt it. From the very beginning, you have to ask yourself — Who can access my application, work with it at the infrastructure level, manage it as the developer or work with it as a user? The answer to this question will help you determine how complex the authorization building process will be.

How microservices changed AuthZ

If you look at this issue in the context of the emergence of microservices, it becomes even more complicated. When you built a monolith application, you had the ability to bake in the decision-making process of who connects to what within the application into just one place — usually by using a specific framework such as Spring, Django, or Python. As you start breaking an application into multiple services, you end up having to replicate the authorization code across each and every microservice. And each time you want to restructure, change something, or add another feature, you have to do it in each microservice separately.

The rising demand for increasingly advanced authorization, the rising complexity of the applications themselves, and their migration to microservices and cloud-native structures magnified the pain of building authorization into the application itself.

The good news is that the field of authorization is adapting, and new solutions to resolve these issues are beginning to develop. These become available now thanks to the overall evolution of the cloud space, both in technology and mindset.

Rethinking services, new technology, and a shift-left midset.

There have been a couple of major developments that allow us to view authorization differently: An advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers.

In terms of technology, to create significant changes in authorization we needed the previous layers — identity management and authentication to be working well. Until we had SAML and SSO connect between identity management and authentication, that entire area wasn’t stable enough to build upon. The maturity of those standards enabled the entire Authentication space to blossom almost a decade ago, and now again with Passwordless. Before we had standards like the JSON Web Token in the authentication layer, it was basically impossible to connect to it in a standardized way. JSON Web Tokens (JWT), which only became mature in recent years, are a great way to communicate from the authentication layer into the application, and specifically into the authorization layer.

The authentication process ends when the JWT is handed to the application — specifically, to the authorization layer within it. While the authentication layer provides claims that affect the access policy, it’s still up to the authorization layer to translate and enforce those claims based on the JWT and, often, additional context data.

In terms of thinking about services, if you go back five years, people were still thinking things like billing, authentication, or databases, being core and critical, require developers to implement them themselves. Thanks to companies like Stripe, Auth0, and MongoDB, developers have realized how complex these issues are, and how problematic it is to try and build them yourself. Thus, a mindset of adopting critical services as part of an application you’re building became legitimate. Moreover — it became a consensus that you have to adapt these kinds of solutions since the risk of making mistakes when trying to build them yourself just isn’t worth it.

The overall trend of shift-left, which has been discussed in the security sphere ad nauseam, and the increasing number of people who are becoming low/no-code developers (eg. product, security, compliance) makes it critical for us to enable them to work on such fundamental experiences as access control.

So what can be done about this?

Modern authorization, finally.

This new reality has created an understanding that new solutions to resolve these issues should be built. Thankfully, the developer community has started creating these solutions with open source projects (e.g. OPA, OPAL). This way, you can adopt them as building blocks into your application without paying anything, and more importantly, they allow you to implement practices that prevent you from repeating the mistakes of the past.

The most important matter here is that while building applications, we understand the complexities that come with creating a functional authorization layer, and the best practices that should be implemented while building it in order to avoid constantly having to rebuild them.

There are already good ready-made solutions (e.g. Permit.io) out there — as open-source or as services that you can build upon while avoiding common mistakes. You can also approach this by building it yourself, but if you choose to do so, you have to do it right.

Summary

The drastic changes in the landscape of authorization over the last few years make it necessary for us to change our mindset and adopt new best practices in order to avoid constantly rebuilding authorization. The advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers created an environment in which we can adopt existing solutions and use them as building blocks for our applications.

Achieving modern authorization was originally published in Permit.io on Medium, where people are continuing the conversation by highlighting and responding to this story.