---- On Tue, 04 Oct 2022 15:28:23 -0700 Andrew Boring wrote ---
Hi all,
I'm looking to support a situation where one class of Keystone users in a given domain can create Swift containers (either within a single, dedicated project or within their own projects) but *cannot* change ACLs on those containers, while a second class of users *can* alter ACLs on their own containers.
For example, User A is in the first class (defined by role) and can perform all CRUD operations, EXCEPT update pre-defined ACLmetadata on those containers. User B is in the second class and CAN update ACLs on their respecitive containers, like any other standard user.
Something like this AWS policy condition ("Granting permissions to multiple accounts with added conditions") is directionally what I'm trying to achieve: https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policie...
Keystone docs imply that I can create policy.json files for all services:
"You can define actions for OpenStack service roles in the /etc/PROJECT/policy.yaml files. For example, define actions for Compute service roles in the /etc/nova/policy.yaml file." -https://docs.openstack.org/keystone/yoga/admin/cli-manage-projects-users-and...
But I can't find any indication that Swift actually supports this.
So, does Swift support the Oslo policy.json stuff, and if so, is it documented anywhere? Is it simply a "install oslo policy and add it to the pipeline in proxy-server.conf"?
Swift does not use the oslo.policy or policy.json file mechanism to control the access on their APIs. I might be able to provide detail about their ACL mechanism but below doc explain some of it:
- https://github.com/openstack/swift/blob/3ad39cd0b83a7f70d6c559c7b0e68a2e625b...
-gmann
If not, is there another/preferred way to achieve the desired restrictions on Swift API operations by policy for a given Keystone domain?
Thanks.
-- Andrew Boring andrew@andrewboring.com