Alternatively, if you want to restrict access to s3 resources for different groups of users, then you can do so by creating a role in a tenant, and then create s3 resources and attach tags to them and then use ABAC/ tags to allow a user to access a particular resource (bucket/ object). Details can be found here: https://docs.ceph.com/en/latest/radosgw/session-tags/ Thanks, Pritha On Wed, Mar 9, 2022 at 9:54 AM Pritha Srivastava <prsrivas@xxxxxxxxxx> wrote: > Hi Mark, > > On Wed, Mar 9, 2022 at 6:57 AM Mark Selby <mselby@xxxxxxxxxx> wrote: > >> I am not sure that what I would like to do is even possible. I was hoping >> there is someone out there who could chime in on this. >> >> >> >> We use Ceph RBD and Ceph FS somewhat extensively and are starting on our >> RGW journey. >> >> >> >> We have a couple of different groups that would like to be their own >> tenants and have a namespace to themselves. They would also like to use STS >> and our internal iDP for short lived credentials. >> >> >> >> We have working POC in the most simple manner using RGW and STS with >> AssumeRoleWithWebIdentity. >> >> >> >> With the Role and Policy shown below I create a bucket and end up with >> the default ownership and ACL as also shown below. >> >> >> >> Ceph RGW ends up creating the user >> "$oidc$cc1cfa5f-b3b2-4370-b80b-7d9492d52dfc" as a map to my iDP user which >> lives in the default no name tenant. All buckets created by this user end >> up in the default no name tenant. >> >> >> >> What I really want to do is assign these “dynamic” users to tenants based >> on Roles/Policies such that I can use iDP aud/sub/azp fields for the >> assignment. >> >> A role always provides access to resources in the tenant in which it is > created. So if you want to have (shadow/dynamic) users in different > tenants, then you will have to create roles in different tenants. > Additionally you will also have to create openid connect providers in each > tenant (since in AWS an OIDC provider belongs to an account and in RGW a > tenant roughly maps to an account.). And then you can have a role trust > policy for every role that will allow a user to assume the role based on > its aud/azp/sub field. > >> >> Is there any way using STS and AssumeRoleWithWebIdentity to assign users >> to tenants or I am stuck with the default tenant. Could it be that I am >> simply not correct Policy statements to attach the users to the correct >> tenanacy. >> >> >> >> I have done a through web search and cannot find any/many examples of >> people trying to use this paradigm >> >> >> >> Thanks! >> >> >> >> # >> >> # Ownership >> >> # >> >> { >> >> "Buckets": [ >> >> { >> >> "Name": "mybuck", >> >> "CreationDate": "2022-02-15T20:30:32.855000+00:00" >> >> } >> >> ], >> >> "Owner": { >> >> "DisplayName": "", >> >> "ID": "$oidc$cc1cfa5f-b3b2-4370-b80b-7d9492d52dfc" >> >> } >> >> } >> >> >> >> # >> >> # ACL >> >> # >> >> { >> >> "Owner": { >> >> "ID": "$oidc$cc1cfa5f-b3b2-4370-b80b-7d9492d52dfc" >> >> }, >> >> "Grants": [ >> >> { >> >> "Grantee": { >> >> "ID": "$oidc$cc1cfa5f-b3b2-4370-b80b-7d9492d52dfc", >> >> "Type": "CanonicalUser" >> >> }, >> >> "Permission": "FULL_CONTROL" >> >> } >> >> ] >> >> } >> >> >> >> # >> >> # Role >> >> # >> >> >> >> { >> >> "Version" :"2012-10-17", >> >> "Statement": [ >> >> { >> >> "Effect": "Allow", >> >> "Principal": { >> >> "Federated": [ >> >> "arn:aws:iam:::oidc-provider/ >> keycloak.acmewidgets.net:8443/auth/realms/acme" >> >> ] >> >> }, >> >> "Action": [ >> >> "sts:AssumeRoleWithWebIdentity" >> >> ], >> >> "Condition": { >> >> "StringEquals": { >> >> "keycloak.acmewidgets.net:8443/auth/realms/acme:app_id >> ":"app001" >> >> } >> >> } >> >> } >> >> ] >> >> } >> >> >> >> # >> >> # Policy >> >> # >> >> >> >> { >> >> "Version": "2012-10-17", >> >> "Statement": { >> >> "Effect": "Allow", >> >> "Action": "s3:*", >> >> "Resource": "arn:aws:s3:::*" >> >> } >> >> } >> >> >> >> -- >> >> Mark Selby >> >> Sr Linux Administrator, The Voleon Group >> >> mselby@xxxxxxxxxx >> >> >> >> This email is subject to important conditions and disclosures that are >> listed on this web page: https://voleon.com/disclaimer/. >> >> >> Thanks, > Pritha > >> >> _______________________________________________ >> ceph-users mailing list -- ceph-users@xxxxxxx >> To unsubscribe send an email to ceph-users-leave@xxxxxxx >> > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |