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.
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.
This post summarizes a recent customer exchange around design principles that guide the development of Katanemo: supporting convenience features only when system features don’t break. I thought it would make for an interesting post for the broader developer community on how we are designed differently.
Does Katanemo support nested user groups?
The short answer is no. The long-answer is “sort of”. Here’s what’s happening underneath the covers. But first a quick primer.
Katanemo is built for developers that are looking to create the next Stripe, Twilio, Figma, etc. Core properties of these successful (cloud-native) apps is that they have rich APIs, which power delightful workflows for users and 3rd party application scenarios. These apps dramatically lower the bar for adoption, and activate more usage through desirable features that meet the highest security standards.
So how does Katanemo help? We match the grooves to the adoption lifecycle of a SaaS app by helping developers build critical on-boarding and security features in minutes. You can build critical authentication capabilities to sign-up users, and effortlessly scale usage within an organization via robust safety, sharing and governance controls (SSO, RBAC/ABAC, Audit logs, etc). Katanemo unifies user, machine and enterprise identity with a fine-grained permissions service - so that you can focus on time to market and features.
While we are different in several ways from others in our space, the one noticeable way is that we don’t support this notion of nested user groups. We support tags - a flat labeling system that resolves at authentication time and enables a more flexible, fast and auditable experience around permissions and access controls.
What are nested user groups? And where did they come from?
User groups as the name suggests is a way to organize users in interesting ways so that administrative tasks can be applied in bulk vs individually- like applying permissions and authorization rules. This idea was popularized by Microsoft Active Directory back in the 90s. And group nesting, simply put, is the process of putting one group inside another group.
Nested groups inherit the permissions and privileges of the group they are put under, and the idea was that this would make privilege access easier. If you update policies at a top-level group, then those permissions would neatly cascade to lower-level groups and with one full swoop the administration of policies around permissions could be made easier. But does it?
While nested groups offer some immediate gratification and convenience benefits - they create for downstream visibility, flexibility, latency, and infrastructure challenges.
To illustrate this via an example, let's look at the following nested group structure. Here the “Built-in Administrator Group” has permissions to all the resources within an application and those permissions don’t traverse to “Brenton” who is a Local user. But If “Brenton” is placed in the “Geeks Local Group” which is part of the “Built-in Administrators Group” then permissions will traverse to Brenton (and Jason) by associative nested memberships.
Naturally, it's convenient to place Brenton in a group where his permissions get elevated so that he can access a particular resource. But here are some key questions:
Should Brenton have overly permissive access available to all administrators?
Imagine, Brenton has to help another team and needs access to resources that fall under a different top-level group. Should he belong to two top-level groups? What if the groups have conflicting permission policies?
If new groups are added between the “Geeks Local Group” and the “Built-in Administrators Group” what is the downstream impact on permissions? Can that impact be easily evaluated? Can we prevent over/under permissiveness?
If groups can be modified (added/removed) at runtime, then how would that impact access latencies?
Modern applications must adapt workflows for today’s dynamic nature of work. Applications are now required to be nimble and adaptable, and this notion that we map users and their memberships in fixed rigid hierarchies doesn’t work anymore. Sure, users and employees will belong to static management hierarchies but their work and collaboration needs are more fluid.
Katanemo support tags - a flat labeling system that resolves at authentication time and enables a more flexible, fast and auditable experience around access controls. Shamelessly, we borrowed the design of our safety and permissions system based on the work we did with AWS IAM during our time there. AWS IAM protects over $100B in cloud workloads at scale and its design principles match to the modern way how people work.
Tags are key and value pairs that act as metadata for organizing users and application resources. Tags can be created to categorize users and resources by purpose, owner, environment, or other criteria. For example our customers (developers) use and enable the use of tags in the following way:
So, let’s borrow from the example above and show how Brenton can be given access to select resources via Katanemo without having to be placed in nested user groups.
Imagine, you’ve built a headless travel app. Your core competency is that you handle all the travel backend infrastructure and separate the presentation layer via Restful APIs. This way your customers can create UI workflows and client side experiences that match to their particular needs. Brenton is designated to manage and operate travel arrangements for executives within an organization. Clearly, Brenton can’t be placed in the “executives” user group - but he can be tagged with appropriate privileges to make changes and view executive bookings.
The above Kataemo policy (an OpenAPI-based permissions language) would grant Breton access to all bookings for executives he manages. The $resourceTags:executive directive tells Katanemo to pull values for the “executive” tag associated with a bookingID, and match all possible values for $principalTags:executives.
$principalTags is a Katanemo directive to pull tags for Brenton. And in this case we want to pull all values for the “executives'' tag so that we can ensure that Brenton only has access to bookings for the executives he supports.
Tags can be used in simple and powerful ways without impacting latencies of authorization workflows. They improve visibility. They match to the more dynamic nature of work, all without compromising security. The trade-off is that resources will need to be appropriately tagged, and users (and other authenticated principals) will also need to be tagged to ensure that safe access controls can be enforced.
Mapping User Attributes to Roles in Katanemo
At the start of this blog post, I mentioned that Katanemo “sort of” supports nested user groups. Yes, we allow developers to provide their customers self-service tools where upstream attributes (like group memberships) can be mapped to a particular Role. This convenience feature does NOT break system features (latency, auditability, flexibility, etc).
This mapping feature essentially allows a specific group membership to be mapped to a particular role. So if your customers already have user groups established upstream, during SSO workflows those attributes can be used to map to particular roles within your application. What they can’t easily do is use this feature to create unbounded recursive lookups on what a user can and cannot do.
Given that we spent a lot of time at large scale cloud providers like AWS and Azure, our design principles borrow from the work we have done with IAM that protect and power cloud services like AWS Lambda, S3, and DynamoDb. Those approaches scaled, protect over 100B worth of workloads, and fit into the modern vernacular that developers are familiar with.
Of course, like any astute reader you are probably wondering if Katanemo supports nested hierarchies for data models. For example, if an application supports the notion of Folders > Files, then users who have access to a Folder should inherit access to Files within it ? I’ll reserve the deep dive on our resource namespaces and our tag-based index for another blog post. Spoiler alert - we use namespaces available in the API schema, create a tag-index for relationships, and add a caching layer for speed.
Hope you enjoyed this post. I’ll have more engineering deep dives around our design principles in posts to follow.
Build modern software companies without the infrastructure tax