Hi Pritha, we are using keycloak and keystone to federate users. Users are able to create keystone projects and use the EC2 credentials to authenticate with radosgw. We also have a panel where a user can access their buckets. Typical cloud provider stuff.
The panel is a client side JS application that used to fetch all the EC2 credentials from keystone and use the first set to do authenticate with radosgw. But because of security concerns we don't want keystone to be public reachable. So we implemented STS with AssumeRoleWithWebIdentity. The user authenticates via keycloak and receives some temporary credentials. We've set a custom user attribute that contains the and map this attribute to the token claim with sub. This attribute is just a string field which will get populated by a middleware, when the user selects the project. We've tried to create the bucket with the STS credentials and access them with the EC2 credentials and vice versa. This was working with 19.2.2 when the keystone und sts uid matched. The buckets that are created via the STS credentials belong to the UID "$oidc$KEYSTONE_PROJECT_ID" while the buckets created via EC2 credentials belong to the UID "KEYSTONE_PROJECT_ID". We also tested this with a local user. We will gather the logs later today. But those basically say "Authentication worked, you don't have access to the bucket of the other uid". I've created a tracker for this problem, where I will add the logs later: https://tracker.ceph.com/issues/74131 Here is how we proceeded with our initial setup that worked with 19.2.2: https://tracker.ceph.com/issues/74131?issue_count=3&issue_position=1&next_issue_id=67889#note-1 Am Mo., 8. Dez. 2025 um 07:08 Uhr schrieb Pritha Srivastava via ceph-users < [email protected]>: > Hi Boris, > > Is it possible for you to elaborate on what problem you are facing? like > which credentials you used to create the bucket? and check rgw logs and see > what the error is, when you try to access the bucket? > > Thanks, > Pritha > > On Fri, Dec 5, 2025 at 5:19 PM Boris <[email protected]> wrote: > > > Hi, > > since the last squid update (19.2.3) we have the problem, that the STS > > integration does not work anymore. (relevant tracker: > > https://tracker.ceph.com/issues/69924) > > > > Now there is a user with the $oidc$ prefix with the same suffix as the > > original user name. For example: > > > > >"$oidc$e0a0eed4f6a64c9cad70b69625dccba8", > > >"e0a0eed4f6a64c9cad70b69625dccba8", > > > > and both user are treated as different users in radosgw. > > > > We user STS with AssumeRoleWithWebIdentity, to make bucket management > > possible via a website, and didn't want to fetch all the access > credentials > > just to pick one and authenticate with that. > > > > Now when we create a bucket in the panel, we don't have access via the > > normal EC2 credentials anymore. > > > > I still think I am holding it wrong. > > This is the role and policy we've set: > > > > > # radosgw-admin role get --role-name=S3Access > > > { > > > "RoleId": "49d0d470-dc7a-4ffe-8db3-4f40cb82ebfd", > > > "RoleName": "S3Access", > > > "Path": "/", > > > "Arn": "arn:aws:iam:::role/S3Access", > > > "CreateDate": "2025-08-12T08:31:11.761Z", > > > "MaxSessionDuration": 3600, > > > "AssumeRolePolicyDocument": > > > "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Federated\":[\"arn:aws:iam:::oidc-provider/vv.xx.yy.zz:8443/realms/snc-customera\"]},\"Action\":[\"sts:AssumeRoleWithWebIdentity\"],\"Condition\":{\"StringEquals\":{\"vv.xx.yy.zz:8443/realms/snc-customera:app_id\":\"account\"}}}]}", > > > "PermissionPolicies": [ > > > { > > > "PolicyName": "Policy1", > > > "PolicyValue": > > > "{\"Version\":\"2012-10-17\",\"Statement\":{\"Effect\":\"Allow\",\"Action\":\"s3:*\",\"Resource\":\"arn:aws:s3:::*\"}}" > > > } > > > ] > > > } > > > > Best wishes > > Boris > > -- > > Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im > > groüen Saal. > > > _______________________________________________ > ceph-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groüen Saal. _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
