Permit.io makes authorization accessible for startups and enterprises

Bart: Welcome to KubeFM. Can you tell us about who you are, what you do, your role, and where you work, which is Permit.io?

Gabriel: My name is Gabriel Manor, and I am the VP of DevRel at Permit.io. As a long-time developer who crossed over into business and developer relations two years ago, I can attest that Permit.io is a startup focused on solving authorization for developers. Authorization is a growing problem and challenge that has been increasing over the last couple of years. Permit has an end-to-end platform for developers who want to implement authorization, from modeling permissions to enforcing them and querying permissions with the user of a resource. Everything is available in the Permit.io platform, allowing developers to choose what they need from Permit.io or handle all the work themselves.

Bart: Gabriel, what do you want to share with us today?

Gabriel: We are going to KubeFM and are excited about it. This is not our first KubeFM; we have been to KubeFM many times. One of the most exciting things we are going to do at KubeFM is announce a new pricing tier and set of features for startups. Traditionally, authorization was something that belonged to large enterprises. I always say that one of the most common standards for developers is "we'll do RBAC later." RBAC is a known term for permissions. We see that changing; many startups want to start their product and deployment with authorization. We now have a special offer for startups and B2C applications that helps them implement fine-grained permissions for about dozens of dollars a month, which is significantly cheaper than any other solution, and certainly cheaper than developing it themselves.

So, what problem or problems does the Permit.io platform solve? I always look at what has changed over the last year to make authorization a significant problem. Having permissions in applications is something that has been around since humans started using computers. Usually, it was quite simple; people used to implement it themselves by modeling permissions with roles or access control. However, over the last couple of years, the amount of data we process has grown exponentially, and we need to ensure it all has the right permissions for users. Cloud native, which is especially important for KubeFM and KubeCon, has made our applications need velocity. We want to ensure that nothing is broken when we deliver new software, and it's distributed. We need to ensure that permissions are streamlined across all our microservices and enforced at the level of APIs, users, backends, databases, etc. Another important thing is that our users now have required privacy and security requirements. Users want to ensure their data is private and that no one can access it without permission.

I believe these three challenges - cloud native architectures, the amount of data, and user requirements - have made authorization and fine-grained permissions something that you don't want to develop yourself, as it's too complex. This is where platforms like Permit.io come into the picture. We understand that authorization is not a problem that can be completely solved as an externalized product. You can't just externalize authorization like you externalize authentication, because there are probably some business logic parts that are part of your permission model. You need to do some configuration, etc. Authorization is continuous; it's not something that happens once, like authentication. Users are verified, then they're allowed, but authorization can happen five or 10 times per API endpoint. We try to have a platform that allows you to use what you need and save time, and then you can develop or integrate things you want to control yourself.

As for the before and after of this product announcement, the "before" is clear: we saw a lot of users starting with Permit.io and then saying, "Okay, we have this, but..." Let me share the old pricing model, the Pro pricing model, which is aimed at enterprise applications. It's driven by monthly active users, the users you authorize or check permissions, and the tenants in your system, the account. For enterprises, that makes a lot of sense. However, for growing startups and B2C applications, you probably have thousands of users with mostly no tenants, and with our traditional pricing tier, Permit.io becomes really expensive. They might choose to go with one of our open-source solutions or another solution. This is why we decided to go with the new startup tier, which is very cheap, even if you have 20,000 users on your platform, for less than $200. I don't remember the exact number, but it gets really cheap for people who just want to implement permissions from day one. And then, if they grow to be more B2B or the startup grows, they can switch to the Pro tier.

One important thing that hasn't changed before and after the announcement is that Permit.io has a policy of no blackout features. Our pricing model is not dependent on the features you have in your application. Everyone has access to all features, even with the free tier. The only thing we control is pricing, quota, and some more enterprise-related features like SSO, but that's not something the startup tier actually needs.

Bart: Is the Permit.io platform open source and part of the CNCF landscape?

Gabriel: So, Permit.io is not an open core product. It's a product that has a lot of open source, and Permit.io is also a maintainer of a project called Opal, the Open Policy Administration Layer. The CNCF landscape includes many great policy engines, such as Open Policy Agent (OPA) and OpenFGA. However, when you need to connect them to a modern application, it can be challenging. You need to manage deployment, synchronize policy, and synchronize data. Opal, the Open Policy Administration Layer, is a large product with 5,000 stars on GitHub and a large community around it. You are invited to contribute to this project, which aims to solve the problem of authorization for application developers by using a policy engine. Permit.io uses Opal as its core engine, and everything that runs on the user side is open source. This means that no matter whether it's the Opal part that you are checking permissions with, or our SDKs, everything related to plugins and CLI - where you can do everything - is open source. Our main agenda is that everything that runs on the customer side is open source, so users can see what they are running and potentially contribute. This is connected to the point I mentioned before: authorization is a problem that keeps developers engaged with your product because they need it for their business and need to integrate it deeply. We see a lot of contributions, even to things that are not traditional open source. For example, our SDKs get a lot of contributions from the community. We have a new tool called Permit CLI, which is a CLI tool for developers who define authorization. It lets them do things like visualize permission graphs, control infrastructure as code for policy configurations, and more.

Bart: I know you mentioned it briefly in a previous question, but what is Permit.io's business model?

Gabriel: The business model correlates with the pricing tier. We charge per monthly active user. Every unique user, service, or entity that we check permissions for is considered an active user, and you pay for the unique ones you have in a month. We call it monthly active users. It doesn't matter if you have a million users; if only a thousand of them log in and check permissions, you'll pay only for a thousand. The main business model is based on this principle. The free tier is up to a thousand monthly active users. You can use Permit.io however you want, and all features are open from day one, with no blackout features. Then, we charge per monthly user, depending on the startup and enterprise, based on how you model your users inside Permit.io. In the startup tier, there is a limitation of 25,000 users in your app. However, there are no limitations on the number of developer seats, instances running to check permissions, or configurations. Everything is open, although there are some limitations on the number of rules you can configure to prevent abuse. These limitations should not affect standard or standard plus users.

Bart: Who are your main competitors?

Gabriel: I know it may sound like a cliche, but as a developer relations expert, I always say that your main competitor as a developer tool is the developers themselves. The main thing we hear from developers is, "I can do that myself." Every time I publish content, I get comments on Reddit saying, "You shouldn't roll out your authorization, you should do it yourself." From the competitor side, one thing to look at is the CNCF landscape. Styra, the company maintaining the Open Policy Agent (OPA) project, mainly sells to DevOps teams who control admissions policies for Kubernetes, but they also sell OPA and OPA Enterprise for application authorization. Another competitor is OpenFGA, a CNCF project backed by Okta, which is also offered as part of Okta's FGA commercial product. There are also smaller competitors like Aserto and Cerbos, which are developing their own policy engines. Something important to consider when looking at competitors in our space is that Permit.io is not building a policy engine. We have a platform for authorization, but you choose what policy engine we run on your behalf. We use Open Policy Agent (OPA) as our main engine, but you can also run your policy with Cedar language or OpenFGA, and in the future, with other policy engines. One of the benefits of Permit.io is that you can extend it. For example, you can get OPA Enterprise and use Permit.io only for modeling the policy, then continue to run your OPA with OPA Enterprise. Some of our customers use AWS Verified Permissions, a product for running Cedar language policies, and they use Permit.io to manage their deployments for the policy engine. So, Permit.io is a platform that has competitors, but it also complements some features that are missing in other products, making it a better option for some users.

Bart: Last but not least, what can we expect next regarding the Permit.io platform and Permit.io more broadly?

Gabriel: We are a startup that is growing really fast. People who are following see that we always get more and more large users and more engagement in the community. One of the most exciting projects we are starting to work on is the Permit.io CLI. The CLI is a developer tool for individual developers who need to work on authorization, need help modeling permissions, need help checking a single permission, or need help setting up CI/CD for permissions.

Bart: Gabriel, thank you very much for all the hard work you're doing. I look forward to hearing about what's going on next for Permit.io. Take care.