How Ceph RGW IAM accounts isolate teams and customers on one cluster
When several internal teams or external customers share one Ceph cluster, separate buckets are rarely enough. Each group usually needs its own administrators, its own users and permissions, and its own storage limits, without being able to see or change anyone else's configuration. The Ceph Object Gateway (RGW) IAM account model is designed for that separation: an account acts as a tenant boundary with its own root user who manages IAM users, groups, roles and policies inside that boundary. Whether your teams need this depends on whether the people administering storage for a group should be able to do so without cluster-wide or shared-tenant access.
The model is described in the Ceph Object Gateway documentation, which covers accounts, IAM APIs and the way RGW evaluates policies. Before you design around it, confirm the exact account settings, the API calls your SDKs and automation will use, and how the feature behaves in your release. Squid (19.2.x) and Tentacle (20.2.x) are the actively maintained releases on the Ceph releases page, but IAM account features, their defaults and their limits can differ between them. Treat the documentation for your target release as the reference for every setting in this section, and test the flow on a non-production cluster first.
A practical starting point is to list each team or customer, the administrators who need self-service, and the operations they must perform without help from the platform team. Map those needs to account root users, IAM users, groups and roles, then decide which account-level quotas apply. Confirm with your Ceph version which account and user quota controls exist and where they are enforced. Also confirm how existing tenant-level users will be moved, because the older tenant-level IAM model is deprecated and migrating from it is a separate planning step that affects application credentials and bucket ownership.
Which isolation model fits each team or customer
This table compares three ways to separate teams or customers on Ceph RGW: shared buckets with per-user access, tenant-level isolation, and account-level IAM with separate root users. Read each row across the columns to see who administers the option, how access and quotas are handled, and when it fits; confirm per-release behavior before you commit to a design.
| Decision point | Shared buckets with per-user access | Tenant-level isolation | Account-level IAM with root users |
|---|---|---|---|
| Who administers it | The operator creates users and buckets and manages bucket policies on the team's behalf | The operator provisions each tenant namespace and its users | The operator creates the account and its root user, then the account owner manages IAM users, groups and roles |
| How access is granted | Bucket ACLs or bucket policies that name individual users | Users inside the tenant are granted access to buckets in that tenant namespace | The account root user creates IAM users, groups, roles and policies that the account controls |
| What the customer can change without the operator | Little: object-level sharing within granted buckets only | Users and bucket permissions inside the tenant, subject to the operator's settings | IAM users, groups, roles and policies within the account, subject to the operator's quotas |
| How quotas and usage are reported | Usually per bucket or per user; confirm which statistics are exposed to each team | Usage is reported at tenant level; confirm how it maps to individual users and buckets | Account-wide usage and quotas are documented; confirm the exact reporting views in your release |
| Separation of names and buckets | Shared bucket namespace, so teams must coordinate bucket names | Bucket names are scoped to the tenant; confirm cross-tenant name behavior for your release | Account scoping gives each owner its own IAM space; confirm how bucket names resolve across accounts |
| Use of deprecated tenant-level IAM | Not applicable | This is the model being replaced; plan a move to accounts and confirm the migration steps for your release | This is the target model; new multi-tenant designs should start here |
| Best fit | A few internal teams that share data and trust one administrator | Existing deployments that already rely on tenants and need time to move | Internal business units or external customers that need self-service IAM and delegated administration |
| Main risk | Access drift as shared buckets grow and policies are edited by hand | Operator workload rises with each tenant, and the model is being phased out | Quota and policy design must be agreed up front, since the customer controls much of the IAM |
Why tenant-level IAM is being replaced and what moving off it involves
Tenant-level identity is the older way RGW separates users, and the account-based IAM model is the one the Ceph documentation now describes for delegated administration. In practice, a tenant is a namespace that groups users and buckets, while an account adds a root user, IAM users, groups, roles and policies that a customer or team can manage without operator help. Moving off tenants is therefore less about renaming buckets and more about deciding who administers each space, which permissions they hold, and how their storage is limited. Confirm the current deprecation status of tenant-level IAM, and any migration tooling or step-by-step guidance, in the Object Gateway documentation for the exact release you run, because support statements and tooling change between releases.
Start with an inventory before changing anything. List every tenant, the users inside it, the buckets each one owns, and the bucket policies and ACLs that grant access across tenant boundaries. Record which tenants map to real owners, which are shared, and which exist only from past testing. Also capture current quotas and usage per tenant and user, since those limits carry into the account model and will need to be recreated deliberately. Ask your Ceph administrator to pull this from the RGW admin interfaces for your release rather than from memory, and keep the output as a dated baseline so you can compare it after the move.
Test client applications before any cutover, especially code and configuration that refers to tenant-prefixed bucket names or assumes a tenant is part of the access identifier. Backup jobs, data pipelines, lifecycle scripts and SDK configurations often hard-code these forms, and a failure may appear only when a rarely used job runs. Build a test matrix covering each application, each bucket it touches, read and write paths, and the credentials it uses after the change. Run it against a non-production RGW zone with a copy of representative data, and keep the previous credentials valid until every dependent system has passed. A rollback plan should state exactly which access keys and bucket names will be restored if a client fails.
Setting up an account, its root user and first IAM users in order
This sequence takes a Ceph RGW cluster from a confirmed release and endpoint to an account whose IAM users can reach only their own buckets. Each step ends with a check you can record before the next one starts.
Confirm the release and RGW endpoint
The platform engineer confirms the Ceph release running in your cluster against the active releases list, then confirms that the Object Gateway daemons answer on the S3 endpoint your applications will use. Record the release, the endpoint URL and the TLS certificate in use. Confirm with your own environment which IAM and STS APIs your release enables, because coverage differs between releases and this check is what the rest of the sequence depends on. The step is done when a plain S3 request to the endpoint succeeds with a test identity and the release is written into the change record.
Create the account and its root user
An administrator creates the account and its root user through the administrative interface the Object Gateway documentation describes for your release. Confirm the exact command or dashboard path in that documentation before the change window, because account administration has changed across releases. Set the account identifier and display name to match your internal naming convention so that later audit records are readable. The step is done when the account appears in the administrative listing and the root user can authenticate to the endpoint.
Record and hand over root credentials
The administrator generates the root user's access key and secret key, stores them in your approved secrets manager, and limits access to a named set of people. Record who holds the credentials, where they are stored and the date they were issued in your access register. Hand the root credentials to the account owner through that controlled channel only, and state that routine work should use IAM users instead. The step is done when the secret is stored, the access register entry exists and no copy remains in tickets, chat or shell history.
Create IAM groups and IAM users
The account owner, using the root credentials or an administrator acting for the owner, creates IAM groups that match the functions inside the team, such as application writers and read-only auditors, and then creates one IAM user per person or workload. Give each workload its own user so its keys can be rotated and revoked without affecting others. Confirm with your release's documentation which IAM user and group operations are supported. The step is done when each user is listed under the account and each user has a single, documented purpose.
Attach policies to groups and users
Attach policies to the groups rather than to individual users wherever possible, and grant the smallest set of S3 actions that the function needs. Scope each resource to the account's own bucket names or prefixes, and keep administrative actions on IAM resources with the root user. Confirm which policy condition keys and actions your release evaluates, because support for some keys is partial. The step is done when a policy review confirms that every statement names a specific resource and that no user holds an unscoped wildcard.
Create a test bucket inside the account
A user with write permission creates a test bucket and uploads a small object, then reads it back with the same identity. Use a bucket name that carries the account identifier so that the ownership is obvious in listings. The step is done when the write and read both succeed and the object appears in the bucket listing that the same user sees.
Test access from a client holding only account credentials
On a client machine that has no other Ceph or administrator credentials, configure the AWS CLI or an SDK your applications use with the account's IAM user keys and the RGW endpoint. Confirm the user can list and read its own bucket and cannot list, read or write a bucket created by another account. Also confirm that a read-only group member cannot write. Record each request and its result. Confirm which SDK versions your applications use, because signing behavior differs between clients. The step is done when every expected allow and every expected denial is recorded and matches the policy design.
Record the baseline and hand over
Record the account identifier, the user and group list, the attached policies, the test results and the credential locations in the operations runbook. Name the owner who approves new users and policy changes, and state how keys will be rotated and disabled when someone leaves. The step is done when the runbook entry is reviewed by the account owner and the security team, and the test results are stored with the change record.
How groups, roles and policies decide what each tenant can do
Ceph RGW gives each tenant an IAM space with its own users, groups, roles and policies, but those pieces only protect data when they are scoped deliberately. The cards below separate the five building blocks so you can decide who gets what, and where a tenant's own administrators must stop.
Groups for shared permissions
A group bundles attached policies so that several IAM users receive the same permissions without copying policy documents into each user. Use groups for stable functional roles inside one account, such as a backup operator team or an application read-only team. The common mistake is attaching permissions directly to individual users, which makes later audits and removals slow. Check that every user in a group should hold every permission the group grants, and confirm with your RGW version which group-level operations are supported.
Roles for assumed access
A role is an identity that a principal assumes for a limited session through the STS API, rather than a long-lived credential. Roles fit workloads that run in one account and need temporary access to another account's bucket, or a CI job that should not hold static keys. The common mistake is writing a role trust policy that accepts any principal. Confirm which STS operations and trust policy elements your Ceph release supports before you design around them.
Policy documents for bucket and action rules
Policy documents are JSON statements that allow or deny S3 actions on named buckets and object prefixes, and they can be attached to users, groups, roles or buckets. Decide whether a rule belongs to the identity, to the resource, or to both, because an explicit deny always wins. The common mistake is the over-broad wildcard, such as an action of s3:* on a resource of *, which grants far more than the tenant's data. Test each policy with the exact SDK calls your applications make.
Bucket ownership versus account ownership
An account owns the buckets it creates, and its IAM identities act on those buckets according to policy, so ownership and access are separate questions. Decide which account owns each bucket before the first upload, because moving ownership later affects quotas, usage reporting and who can change bucket policy. The common mistake is letting every application share one owning user, which makes it impossible to tell which workload wrote which data. Confirm how your release reports usage per account and per bucket.
The admin boundary a tenant cannot cross
The admin boundary separates what a tenant's account administrator can manage from what only the cluster operator can change, including the global RGW configuration, other accounts, quotas set at the cluster level and the zone configuration. Write this boundary down before onboarding a customer, and confirm which account-level and user-level IAM actions your release allows a tenant administrator to perform. The common mistake is granting tenant administrators a capability, such as managing quotas or policies on shared buckets, that the platform team assumed it still controlled.
Setting account quotas for internal teams versus external customers
On an internal shared platform, an account quota usually caps the total capacity a business unit or product team may consume from the cluster, so one team's growth does not starve the others. The quota works mainly as a planning control. It is set from an agreed capacity plan, reviewed when that plan changes, and tied to the owner who requests more space. A full quota typically causes writes to fail with an error that the application must handle, so teams should learn about approaching limits through their own alerts well before that happens.
- Cap: the account total that reflects each team's agreed share of cluster capacity, reviewed on the same cycle as the capacity plan.
- Who sees reports: platform engineers see every account, while team leads see their own account through an agreed channel such as a dashboard or a scheduled report.
- Customer experience: internal users see application errors on upload, so agree in advance how those errors are displayed and who the team should contact.
- Operator monitors: per-account usage trend, projected time to reach the cap, and raw cluster headroom, because account quotas cannot promise more space than the cluster holds.
- Change control: record who approved each quota change and why, so requests from teams can be traced later.
Confirm with your Ceph release which usage and quota reporting commands and dashboard views are available before you promise teams a reporting schedule.
When you run object storage as a managed service for external customers, the account quota becomes part of the commercial agreement. The cap should map to what the customer contracted for, and each customer must see only its own usage. The customer's experience of a full quota matters most here, because it directly affects their applications and their trust in your service. Warnings, reporting and error handling should be agreed in the service terms and built into your customer portal or API before go-live.
- Cap: the account limit matched to the contracted allocation, with a documented process for upgrades when a customer needs more.
- Who sees reports: customers see their own usage through a portal or API you build, and your operations staff see all tenants for support and capacity work.
- Customer experience: writes fail once the limit is reached, so customers need a clear error message, a notification before the limit, and a named support route.
- Operator monitors: usage against each contracted cap, sustained growth that signals a renewal or upgrade, failed writes by account, and any one tenant that affects shared cluster performance.
- Cost components: the quota itself is only one part of the work, since the portal, metering, billing feed and support process are separate items to scope and price.
Ask any partner to show in writing how usage data is isolated between customers and how quota notifications reach them.
For regulated workloads, the account quota often supports cost allocation and evidence rather than only capacity planning. The cap is tied to a budget center, usage figures feed a chargeback process, and both the figures and the quota history must be reproducible for finance teams and independent auditors. DeployOpen can prepare systems, controls and evidence for an assessment, but auditors and certification bodies issue the assessment outcome. Quota behavior for records that must not be lost should be agreed with application owners before any limit is set.
- Cap: the account limit linked to an approved budget line, with each change recorded alongside its approval.
- Who sees reports: finance receives period-close usage figures, compliance receives retained evidence of quota settings and changes, and application owners see their own consumption.
- Customer experience: internal consumers of regulated records need defined behavior for a full quota, such as a hold on new writes with an alert to the owner, rather than silent loss of data.
- Operator monitors: usage snapshots taken at each period close, reconciliation between storage usage and chargeback amounts, and any unplanned quota change.
- Retention: keep usage snapshots and change records for the period your finance and assessment requirements specify, which should be confirmed with those owners.
Before finalizing chargeback, check that the usage figures you report can be reproduced from retained data, and see the sibling page on Ceph RGW quotas for accounts, users and buckets for the bucket and user limits that sit beneath these account caps.
Securing root users, access keys and admin paths for each account
Each account in an RGW multi-tenant design holds its own root user, keys and administrators, so one leaked credential or over-broad admin can reach a whole customer or team. The cards below cover the controls that limit that exposure and the checks to run before you hand an account to a tenant.
Root user credential handling
The account root user holds the broadest rights inside its account, so its credentials should be generated during account setup, stored in your secrets manager, and never used for routine automation. Ask who can read the initial secret, how it is delivered to the account owner, and whether a rotation procedure exists and has been tested. A CISO's first question is usually who can still log in as root after handover, so record that answer before go-live.
Rotation of access keys
Access keys for IAM users and applications are long-lived unless you rotate them, so a key copied into a CI job or a laptop can outlive the person who created it. Define a rotation interval per account, track which application uses which key, and confirm that the RGW admin tooling can create a new key and disable the old one without downtime. Test this on a non-production account first.
Least-privilege IAM policies
IAM policies in RGW can grant actions on buckets and resources, so the default risk is a policy that uses broad wildcards copied from an example. Write policies per group or role, deny by default, and review each statement against the S3 operations the application really calls. Ask the account owner to name the buckets and actions each team needs, and reject any request for full account access without a documented reason.
Short-lived credentials through STS
Temporary credentials issued through the AWS STS API expire on their own, which limits the damage from a stolen token compared with a static access key. Decide which workloads should assume roles instead of holding keys, and check that your RGW release supports the STS and role operations those workloads depend on. Confirm the exact STS coverage for your release in the Object Gateway documentation before you design around it.
Multi-factor authentication for admins
The Object Gateway documents multi-factor authentication, which is a control to evaluate for human accounts that can change policies, rotate keys or create users. Confirm which MFA method your release supports, whether it applies to the account administration path or only to specific user types, and how recovery works when a device is lost. Record the answer in the access design, since a CISO will ask whether administrative actions require a second factor.
Separating cluster admin from account admin
Cluster administrators control RADOS, the gateway daemons and the realm, while account administrators should manage only their own users, groups and buckets. Keep these roles on separate credentials and separate change paths so a tenant administrator cannot change cluster-wide settings, and a cluster operator does not hold tenant secrets by default. Document which person or group holds each role and who can grant the cluster role.
Single sign-on for dashboard access
The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Whether this covers account administration in the RGW user and account interfaces, or only the dashboard views, depends on your release and configuration, so confirm it before you promise central sign-in for tenant admins. Until confirmed, plan for local admin credentials with a documented break-glass process.
Audit logging of account changes
Account, user, group, role and policy changes are the events an auditor will ask you to reconstruct, so decide where they are recorded and who can read those records. Confirm which RGW operations generate logs, where they are stored, how long they are kept, and whether they are shipped to a store that account administrators cannot edit. Test by creating and deleting a test user and checking that the change appears in the log.
What account-based IAM costs and what the work needs from your team
What does it cost to design and build an account-based IAM model on Ceph RGW?
No fixed price applies across deployments, because cost follows the written scope. The work has three parts: designing the account and policy model, building it on your RGW endpoints, and testing it with the applications that will use it. Design effort rises with the number of distinct tenant types, the number of roles each tenant needs and how much delegation you want to give account administrators. Build effort covers account creation, user and role provisioning, policy templates and quota settings. Testing effort depends on how many client applications and SDKs must be checked. Ask for the cost of each part separately so you can see which one changes if the scope changes.
Can our own team design and build account-based IAM for RGW without a partner?
Yes, if your team already runs Ceph and understands S3 authorization. The RGW IAM and STS APIs are documented in the Ceph Object Gateway docs, and the work is mostly careful modeling and repeatable automation. Teams often struggle with three areas: the difference between account root users, IAM users and roles, the way policies are evaluated across those identities, and testing that a tenant cannot reach another tenant's buckets. Check whether your engineers have time to build a test suite that covers those cases. A partner is most useful when the deadline is fixed or the tenant count is large enough that migration risk becomes the main concern.
What makes the effort grow for multi-tenant IAM on RGW?
The main drivers are the number of tenants, whether existing tenants must be moved, how deeply SSO is integrated, the complexity of your policies and how many client applications you must test. Each tenant adds accounts, users, groups, roles, quotas and tests, so the count multiplies work. Moving from deprecated tenant-level IAM requires mapping existing users and buckets to accounts without breaking access for running applications. SSO integration adds identity provider configuration and role mapping. Policy complexity grows with fine-grained conditions and cross-account access. Client testing grows with every SDK, tool and language your teams use against the endpoint.
What should we ask for in a written quote for account-based IAM work?
Ask for a fixed-scope quote with a written list of deliverables. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that scope. Useful items to request include:
- The account and role model, with the tenant types it covers
- The number of accounts, users and roles to be created or migrated
- Whether existing tenant-level users and buckets are in scope for migration, and how cutover is handled
- The SSO integration points and the identity provider involved
- The list of client applications and SDKs to be tested, and the test evidence delivered
- Operating documentation, handover sessions and any retainer for later changes
Ask what is one-time and what recurs, such as quota reviews or support.
How long does an account-based IAM project on Ceph RGW take?
Duration depends on the same drivers as cost: tenant count, migration of existing tenants, SSO depth, policy complexity and the number of client applications to test. A small pilot with one or two tenant types usually moves faster than a full migration of a shared cluster. Your timeline should also account for your own review cycles, change windows and the time needed to confirm application behavior in a staging environment. DeployOpen does not publish durations, so ask for a timeline tied to the written scope and to the milestones in it.
What must our team provide before IAM work can start?
Plan to provide a client inventory, a list of the applications and SDKs that call the RGW endpoint, the current tenant and user layout, and the bucket ownership map. You also need access to a non-production RGW cluster or a staging zone, identity provider details if SSO is in scope, and named owners for each tenant who can approve roles and quotas. Test applications are essential: without real client code or representative scripts, the test phase cannot prove that existing access keeps working. Confirm these inputs with your own environment before the quote is agreed.
Which risks should we check for before paying for IAM design work?
Check how the proposed model handles access that already works. The most common risks are breaking existing signed requests during a tenant migration, granting an account administrator more rights than intended, and leaving quotas unset so one tenant consumes shared capacity. Also confirm which RGW IAM and STS features your clients actually call, because a feature missing from a client's SDK can fail silently. Ask the partner to show how the design will be tested and what evidence you receive at the end.
Limits to confirm for account IAM in your Ceph release
Account-scoped IAM in Ceph RGW depends on the exact release you run, how your zones are configured, and which clients your teams use. The cards below list the limits to verify on a test cluster before you migrate tenants or write account policies.
Supported IAM and STS actions
Account IAM, STS and policy support differs between releases and is not uniform across every API action. Compare the actions your tenants need (user, group, role and policy management, plus role assumption) against the RGW documentation for your release. Then create each action on a test cluster under an account and record which calls succeed, fail or return an unexpected error code.
Account behavior in multisite zones
Accounts, users and policies are metadata that must replicate across zones. Confirm how account objects, IAM resources and quota settings propagate between your master and secondary zones, and what happens to writes made while a zone is unreachable. Test a create, update and delete of an account and a role on both zones before relying on them in production.
Mapping existing tenants to accounts
Tenants created under the older tenant-level model do not automatically become accounts with the same owners, buckets and policies. Decide how each tenant maps to an account, which user becomes the account root, and how bucket names and ARNs change for existing clients. Run the mapping against a copy of your metadata and check that every bucket remains reachable under its expected identity.
S3 clients and SDK support
Account-scoped access depends on how each client builds requests, signs them and handles ARNs, paths and session tokens. Test the SDKs and tools your applications use, including backup software and data pipelines, with an account root user, an IAM user and an assumed role. Record any client that ignores account prefixes or cannot pass a session token.
Release support window
Support windows set how long you can run without a forced upgrade. The Ceph releases page lists Squid with an estimated end of life of October 31, 2026, and Tentacle with an estimated end of life of June 1, 2027. Put these dates in your upgrade plan, and note that the estimates may change, so confirm them on the releases page before you commit.
Backports and security fixes
The releases page states that actively maintained releases receive periodic backports and security fixes. Ask whether the IAM and account fixes you depend on land in your chosen point release, and how quickly security fixes reach it. Treat any account-scoped authorization bug as a release blocker, and schedule point-release updates in your change calendar.
How DeployOpen scopes, builds and supports Ceph RGW account IAM
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph RGW account IAM for multi-tenant S3. The work starts with a written scope that defines which accounts, roles and policies are in play before any configuration changes are made.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists the tenant model, account root users, IAM users, groups, roles and policies to be configured.
- Scope also records which tenant-level IAM users and buckets must migrate, and how existing client access will be preserved.
How we build
- Accounts, IAM users, groups and roles are created in a staging RGW zone before anything touches production tenants.
- Policies are written against the S3 and IAM actions each team's applications actually call, then tested with their SDKs.
- Account quotas and usage reporting are configured and checked against the limits the written scope defines.
How we hand over
- Deliverables include the account and policy model, role definitions, and a record of each configured tenant.
- Runbooks cover creating accounts, rotating root credentials, adding users and reviewing quota and usage reports.
- Your team receives test results showing which policies allow and deny the requests named in the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover policy reviews when new tenants are onboarded and when Ceph releases change IAM behavior.
- Confirm response terms, upgrade scope and access arrangements in the retainer agreement before work begins.
