Every shared storage system runs into the same problem eventually. One team owns the infrastructure, and everyone else files a ticket to get anything done. Need a new bucket? Ticket. New user? Ticket. Change a permission? Ticket. The storage admin becomes the bottleneck, and the people actually using the storage have no autonomy. Ceph, the open source distributed storage system, shipped a feature in its Squid release that makes this better: IAM accounts. This talk covers what that means, why it matters even if you've never touched Ceph, and how it borrows a well-understood idea from the cloud to solve a problem every shared system has.
Think of an office building with one set of master keys, held by a single facilities manager. Every time a tenant wants to add a lock, change who gets into a room, or let in a new employee, they have to call the manager. That's fine while a few teams share the building. Once there are dozens, the manager is the bottleneck and everyone's waiting on them. The fix isn't to hire more managers. It's to give each tenant their own keys for their own floor, while the building owner still controls the building.
That's the problem this talk is about, in the context of storage. When many teams share one cluster, the admin ends up doing everyone's routine chores: creating users, handing out access keys, writing permission policies, making buckets. It doesn't scale, and it puts an operator in the loop for work that isn't really theirs to do.
IAM accounts solve this by drawing a clear line. The admin creates an account and sets its limits: how much storage it gets, how many users it can have. After that, the account runs itself. Whoever owns it can create their own users, hand out their own keys, and write their own access policies, without ever touching the cluster's internal controls. The admin keeps the building. The tenant gets their floor.
The neat part is that Ceph didn't invent a new way to do this. It implemented the same API that Amazon's IAM uses, the one a large chunk of the industry already knows. So the same mental model, and often the same tooling, that people point at AWS works against a self-hosted Ceph cluster. For anyone who'd rather build their own cloud than rent one, that's the whole point: cloud-style, self-service access control on infrastructure you own and run, with no vendor and no per-request bill.
So, in the talk I'll:
Set up the problem with the office-building analogy, so nobody needs prior storage knowledge to follow along.
Walk through the three roles that make it work: the admin who owns everything, the account owner who runs their own slice, and the end users who live inside it.
Do a short demo: an admin creating an account and then stepping away, and the account owner managing their own users and permissions with familiar tooling. In other words, a walkthrough of the IAM feature set itself.
Be upfront about the edges. Ceph's S3 and IAM surfaces have always been a best-effort reimplementation of an interface Amazon owns and keeps extending, so they're chasing a moving target. Ceph's own docs say RGW implements a subset of the S3 policy language, with no string interpolation and only a handful of supported condition keys against AWS's much larger set. I'll show where that subset ends and what you have to reason about before leaning on these policies in production.
There's a wider lesson worth pulling out here too. When an open source project reimplements a commercial API it doesn't control, it's permanently chasing a target. Full parity never arrives, and it isn't really the goal. Picking which subset to implement well, and being upfront in the docs about where the edges are, is a far more sustainable strategy than pretending to be a drop-in clone. Ceph's S3 and IAM work is a good case study in that trade-off.
The goal is that someone who's never run a storage cluster walks out understanding both the feature and the principle behind it.
