In this post, I'll walk you through how we used OpenAPI (and soon GraphQL) as the foundation of a slick permissions experience to help developers build privacy and sharing controls (for their apps) in minutes. 

‍

Today, developers are faced with two simultaneous challenges: they must build meaningful collaboration features for success (think Figma, Notion, Github) and help their customers achieve the principle of least privilege. Developers must preserve privacy in face of sophisticated attackers, and the principle of least privilege minimizes the attack surface, diminishing avenues a malicious actor can use to access sensitive data or carry out an attack.

‍

If developers want to build privacy, permissions and sharing controls, how would they go about doing that today? Well there are a lot of infrastructure-related investments needed (decision engine, policy store, meta-data store, etc.) to support this critical use case, but on a foundational level: they would have to adopt or define a DSL (domain specific language) where controls can be specified. 

‍

If a permissions DSL would be used only for internal purposes, where engineers and operators are trained on its intricacies, it would be one thing. But when this DSL is exposed to customers to define their own least-privilege controls that internal complexity and education becomes a big burden. Now customers are burdened with concepts and semantics not familiar to them. And the biggest enemy of security is complexity.

‍

Our manifesto captures thinking on using open standards to create developer delight. And because we are building for developers with an API-first mindset, we were able to build a slick permissions and sharing experience using OpenAPI (and GraphQL) as the foundation for an authorization and permissions framework. 

‍

Why OpenAPI?

OpenAPI is an interface definition language for describing, producing, consuming and visualizing RESTful functionality. The OpenAPI spec neatly captures service resources, resource paths and already offers a great foundation for authorization via HTTP methods. This means your subscribers don’t have to learn a policy language, you don’t need to maintain  a policy evaluation engine, or create the necessary infrastructure to scale and secure authorization calls.

‍

By leveraging an open specification as the basis of our permissions language, we help customers improve the readability, understanding and construction of access controls. When securing access to resources is made simple, we've removed the worst enemy of security: complexity. Below is the OpenAPI specification of Katanemo's APIs.

‍

‍

‍^{Note: APIs are a disruptive way to deliver software, proven by the likes of Stripe, Twilio and AWS. If you don’t have an API strategy, consider adopting one or risk getting disrupted.}

For RESTful APIs Katanemo supports an OpenAPI-based policy language. OpenAPI neatly captures RESTful API definitions, resource schemas and establishes a great foundation for authorization and auditing.With familiar RESTful semantics customers don’t need to learn yet another policy language. Instead customers focus on defining accurate authorization strategies in logical and idiomatic ways. Katanemo reduces permissions complexity, improves readability and understanding of access controls, and enables customers to easily achieve the principle of least privilege. 

‍

The following is an OpenAPI-based permission policy for an SaaS application where users can get and update the cluster resource via the /cluster API.
‍

‍

where clause

In some cases a simple permissions policy like the ones shown above can’t satisfy strict security requirements. For such scenarios Katanemo allows customers to define conditional policies using the “where” clause. Katanemo’s “where” clause is modeled after the popular SQL where clause to make construction of policies simple to understand and deploy.

‍

The following policies show you can construct simple yet strictly precise permissions policies and associate them with authorization principals like users, machines, etc. Example Authorization Use Case: Interns should have READ/WRITE access to dev clusters, and READ access to stage & prod clusters.‍

‍

‍

Note: $resourceTags, $request, and $principalTags are reserved Katanemo variables that can be used in the where clause to construct precise authorization policies. In the above example, Katanemo retrieves values for the “cluster” tag on the {clusterId} resource, and checks to see if the tag value is either “staging” or “production”. Learn more about resource access via Katanemo Tags.

‍

Katanemo helps your customers achieve least-privilege access controls using an incredibly simple, standards based, permission language (OpenAPI, GraphQl). Your customers won’t have to choose between security and a great user experience, while you ensure that RBAC, ABAC, and Resource-level permissions follow strict causal ordering, and operate under <1ms (P90).