August 10, 2023

A permissions language based on an API language

Adil Hafeez
Founding Member, Engineering
Happy Daylight Savings Week! As we adjust our clocks and our sleep schedules, spring forward with us as we dive into what we shipped in February.

What’s new

Modern Security for Modern Applications
Curabitur at mauris magna. Duis sollicitudin odio in arcu ornare, quis pulvinar eros facilisis. Nunc a sodales ex. Nam sagittis diam maximus lorem aliquam, a tincidunt ante rutrum. In facilisis risus tellus, mollis viverra massa fringilla et. Nunc porta risus mauris, non egestas libero vulputate a. Fusce consectetur convallis orci eu consectetur.
Mauris vestibulum orci sit amet turpis finibus
Curabitur at mauris magna. Duis sollicitudin odio in arcu ornare, quis pulvinar eros facilisis. Nunc a sodales ex. Nam sagittis diam maximus lorem aliquam, a tincidunt ante rutrum. In facilisis risus tellus, mollis viverra massa fringilla et. Nunc porta risus mauris, non egestas libero vulputate a. Fusce consectetur convallis orci eu consectetur. Donec convallis sollicitudin egestas. Vestibulum nec augue non arcu faucibus rhoncus.
Nulla ac ligula commodo, volutpat diam nec, tempor mauris.
Vestibulum malesuada, augue egestas varius scelerisque, tellus massa ultricies nibh, in malesuada est diam id lacus. Fusce vel imperdiet enim, nec porttitor felis. In aliquam quam a erat placerat sodales. Class aptent taciti sociosqu ad litora torquent per conubia nostra.
Quisque imperdiet, neque accumsan eleifend porttitor
In eu finibus eros. Donec in tortor tincidunt, laoreet eros a, ornare lorem. Nulla ac ligula commodo, volutpat diam nec, tempor mauris. Nunc faucibus mi dolor, sit amet fermentum est egestas sed. In sodales malesuada risus id imperdiet. Nunc hendrerit ultrices volutpat. Mauris tincidunt volutpat odio, vel luctus risus imperdiet a.
New keyboard shortcuts for search in Metronome UI
Nulla facilisi. Curabitur dolor diam, faucibus vel ipsum ut, varius rutrum elit. Nunc at odio neque. Fusce vulputate porta mauris. Nam eu sem efficitur leo tincidunt hendrerit. Aenean porttitor metus et metus mollis tristique. Phasellus at cursus quam. Etiam sodales mi ac suscipit dapibus. Aliquam justo dui, ullamcorper efficitur orci a, lobortis auctor lacus. Suspendisse accumsan dui in vulputate finibus. Mauris vel porttitor ligula. Aliquam ut mollis augue. Aenean posuere diam a consequat scelerisque. Etiam molestie arcu gravida turpis pharetra elementum. Ut venenatis eleifend diam ut blandit.

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.

snippet of the OpenAPI spec for Katanemo's identity and fine-grained authorization 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.

simple RESTful-based authorization policy

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.

Katanemo's support for where (conditional logic) clause in its permissions language

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).

Build modern software companies without the infrastructure tax

Want to learn more about our platform?

@katanemo 2023
TermsPrivate Policy
@katanemo 2023