Currently access to radosgw requires project membership. That's more access than most service accounts for reading and writing to object storage need, so there should be a separate role that allows access to Rados but nothing else.
Description
Description
Details
Details
Related Changes in Gerrit:
Event Timeline
Comment Actions
In a perfect world this role would be managed with tofu (T396671) but it's trivial to create by hand, and the good bits are going to be in the ceph config.
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2025-06-11T21:58:25Z] <andrewbogott> created new keystone role in eqiad1 and codfw1dev, 'object_storage' T396594
Comment Actions
Change #1155775 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] Add radosgw access for members of the new 'object_storage' role.
Comment Actions
Change #1155775 merged by Andrew Bogott:
[operations/puppet@production] Add radosgw access for members of the new 'object_storage' role.
Comment Actions
Minor problem: this role doesn't have access to create ec2 creds:
taavi@cloudcontrol1007 ~ $ export OS_PASSWORD=... taavi@cloudcontrol1007 ~ $ openstack --os-auth-url https://keystone.openstack.eqiad1.wikimediacloud.org --os-username toolsbeta-logging --os-domain-id default --os-project-name toolsbeta-logging ec2 credentials create You are not authorized to perform the requested action: identity:ec2_create_credential. (HTTP 403) (Request-ID: req-ae61f6c3-affa-4197-a49d-76bbbf2dac38)
The ec2 credential policies are set to rule:admin_or_owner which doesn't include this new role.
Comment Actions
Change #1163864 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] keystone policy: allow object_storage role to create/delete ec2 creds
Comment Actions
Change #1163864 merged by Andrew Bogott:
[operations/puppet@production] keystone policy: allow object_storage role to create/delete ec2 creds