On Wed, Aug 19, 2026 at 5:20 PM Christopher Durham <ceph-users@ceph.io> wrote:
The release notes for ceph tentacle, at: https://docs.ceph.com/en/latest/releases/tentacle/ state the following "RGW: The User Account feature introduced in Squid provides first-class support for IAM APIs and policy. Our preliminary STS support was based on tenants, and exposed some IAM APIs to admins only. This tenant-level IAM functionality is now deprecated in favor of accounts. While we’ll continue to support the tenant feature itself for namespace isolation, the following features will be removed no sooner than the V release: Tenant-level IAM APIs including CreateRole, PutRolePolicy and PutUserPolicy, Use of tenant names instead of accounts in IAM policy documents, Interpretation of IAM policy without cross-account policy evaluation, S3 API support for cross-tenant names such as Bucket=’tenant:bucketname’ STS Lite and sts:GetSessionToken."
Does the 'V' release mean the Vampire release? Does this statement mean that those API calls will be available in all tentacle releases and umbrella, but maybe not vampire?
that's right, Chris
I need to have the CreateRole,PutRolePolicy et al available in tentacle and do a planned transition to IAM users/roles. Any documentation on how to do this? I have STS roles for various groups of users to gain temporary access to solme number of buckets and I want to be sure my upgrade to tentacle will be ok. (I am on 19.2.5 squid). We are not using tenants but buckets owned by various s3 users and roles to give temporary access to buckets by other users. We have been doing this since either nautilus or octopus and it has worked well for us. (We do not use the gui for role management but have our own python scripts to add users/buckets to roles).
https://docs.ceph.com/en/squid/radosgw/account/#migrate-an-existing-user-int... shows how to migrate existing users into an account, but not how to migrate existing roles. you'll need to create new roles in accounts and delete the old ones because the initial sts implementation treated the tenant like an account, the most direct mapping would be to create one account per tenant (in your case just the global/unnamed tenant) and migrate all of that tenant's users into it. you could then recreate the roles in that account, with role policy that names the same buckets and user principals. however, all buckets would be owned by the account and no users would have any access by default. so you'd have to use iam policy to control all permissions, not just to facilitate sharing between users/buckets if there are distinct groups of ownership/sharing, it would make more sense to create separate accounts for each. users within each account could be granted direct access to that account's buckets, and account roles could be used to share access to some of those buckets with other trusted accounts/users. you'd also have the option to give the account root user's credentials to someone in that group so they could use the iam apis to manage the sharing of their own resources. it's this self-service aspect of accounts that most differentiates it from the tenant-level sts support, which was an admin-only feature if you do decide to put all of the users in a single account, you might consider using iam groups rather than roles. you could use group policy to grant access to specific buckets in the account, then manage group membership with iam:AddUserToGroup/RemoveUserFromGroup. this would avoid the need for role trust policy to name all of the individual users, and those users wouldn't need to go through AssumeRole for that shared access
-Chris
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io