External Auth (AssumeRoleWithWebIdentity) , STS by default, generic policies and isolation by ownership
Hello ceph-users, unhappy with the capabilities in regards to bucket access policies when using the Keystone authentication module I posted to this ML a while back - https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/S2TV7GVFJTW... In general I'd still like to hear how others are making use of external authentication and STS and what your experiences are in replacing e.g. Keystone authentication In the meantime we looked into OIDC authentication (via Keycloak) and the potentials there. While this works in general, AssumeRoleWithWebIdentity comes back with an STS token and that can be used to access S3 buckets, I am wondering about a few things: 1) How to enable STS for everyone (without user-individual policy to AssumeRole) In the documentation on STS (https://docs.ceph.com/en/quincy/radosgw/STS/#sts-in-ceph) and also STS-Lite (https://docs.ceph.com/en/quincy/radosgw/STSLite/#sts-lite) it's implied at one has to attach an dedicated policy to allow for STS to each user individually. This does not scale well with thousands of users. Also when using a federated / external authentication, there is no explicit user creation "A shadow user is created corresponding to every federated user. The user id is derived from the ‘sub’ field of the incoming web token." Is there a way to automatically have a role corresponding to each user that can be assumed via a OIDC token? So an implicit role that would allow for an externally authenticated user to have full access to S3 and all buckets owned? Looking at STS Lite documentation, it seems all the more natural to be able to allow keystone users to make use of STS. Is there any way to apply such an AssumeRole policy "globally" or for a whole set of users at the same time? I just found PR https://github.com/ceph/ceph/pull/44434 aiming to add policy variables such as ${aws:username} to allow for generic policies. But this is more about restricting bucket names or granting access to certain pattern of names. 2) Isolation in S3 Multi-Tenancy with external IdP (AssumeRoleWithWebIdentity), how does bucket ownership come into play? Following the question about generic policies for STS I am wondering about the role (no pun intended) that the bucket ownership or tenant play here? If one creates a role policy of e.g. {"Version":"2012-10-17","Statement":{"Effect":"Allow","Action":"s3:*","Resource":"arn:aws:s3:::*"}} Would this allow someone assuming this role access to all, "*", buckets, or just those owned by the user that created this role policy? In case of Keystone auth the owner of a bucket is the project, not the individual (human) user. So this creates somewhat of a tenant which I'd want to isolate. 3) Allowing users to create their own roles and policies by default Is there a way to allow users to create their own roles and policies to use them by default? All the examples talk about the requirement for admin caps and individual setting of '--caps="user-policy=*'. If there was a default role + policy (question #1) that could be applied to externally authenticated users, I'd like for them to be able to create new roles and policies to grant access to their buckets to other users. Regards Christian
Hi Christian, Replies are inline. On Wed, Mar 15, 2023 at 9:27 PM Christian Rohmann < christian.rohmann@inovex.de> wrote:
Hello ceph-users,
unhappy with the capabilities in regards to bucket access policies when using the Keystone authentication module I posted to this ML a while back -
https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/S2TV7GVFJTW...
In general I'd still like to hear how others are making use of external authentication and STS and what your experiences are in replacing e.g. Keystone authentication
In the meantime we looked into OIDC authentication (via Keycloak) and the potentials there. While this works in general, AssumeRoleWithWebIdentity comes back with an STS token and that can be used to access S3 buckets, I am wondering about a few things:
1) How to enable STS for everyone (without user-individual policy to AssumeRole)
In the documentation on STS (https://docs.ceph.com/en/quincy/radosgw/STS/#sts-in-ceph) and also STS-Lite (https://docs.ceph.com/en/quincy/radosgw/STSLite/#sts-lite) it's implied at one has to attach an dedicated policy to allow for STS to each user individually. This does not scale well with thousands of users. Also when using a federated / external authentication, there is no explicit user creation "A shadow user is created corresponding to every federated user. The user id is derived from the ‘sub’ field of the incoming web token."
Is there a way to automatically have a role corresponding to each user that can be assumed via a OIDC token? So an implicit role that would allow for an externally authenticated user to have full access to S3 and all buckets owned? Looking at STS Lite documentation, it seems all the more natural to be able to allow keystone users to make use of STS.
Is there any way to apply such an AssumeRole policy "globally" or for a whole set of users at the same time?
I just found PR https://github.com/ceph/ceph/pull/44434 aiming to add policy variables such as ${aws:username} to allow for generic policies. But this is more about restricting bucket names or granting access to certain pattern of names.
2) Isolation in S3 Multi-Tenancy with external IdP (AssumeRoleWithWebIdentity), how does bucket ownership come into play?
Following the question about generic policies for STS I am wondering about the role (no pun intended) that the bucket ownership or tenant play here? If one creates a role policy of e.g.
{"Version":"2012-10-17","Statement":{"Effect":"Allow","Action":"s3:*","Resource":"arn:aws:s3:::*"}}
Would this allow someone assuming this role access to all, "*", buckets, or just those owned by the user that created this role policy?
AssumeRole* APIs allow access to buckets owned by the user that creates
Attributes based access control has been added to STS, where tags can be attached to users and resources and generic policies can be written using them like the following ( https://docs.ceph.com/en/quincy/radosgw/session-tags/): { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":["s3:*"], "Resource":["*"], "Condition":{"StringEquals":{"s3:ResourceTag/Department": "${aws:PrincipalTag/Department}"}} }] } the role. In case there is a generic role policy which allows s3:* actions, the federated user/ local user assuming a 'role' will be allowed to create and own a bucket in the tenant in which the role already exists. Although a typical use case for AssumeRole API is to give access to existing buckets of users in a tenant (cross account access).
In case of Keystone auth the owner of a bucket is the project, not the individual (human) user. So this creates somewhat of a tenant which I'd want to isolate.
3) Allowing users to create their own roles and policies by default
Is there a way to allow users to create their own roles and policies to use them by default? All the examples talk about the requirement for admin caps and individual setting of '--caps="user-policy=*'.
A user needs to have perms to create a role or a user policy.
If there was a default role + policy (question #1) that could be applied to externally authenticated users, I'd like for them to be able to create new roles and policies to grant access to their buckets to other users.
Externally authenticated users can be allowed to create new roles by allowing iam actions like 'iam:CreateRole', 'iam:PutRolePolicy' in the role
policy that the external user assumes. But there is no default role + policy.
Regards
Christian _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (2)
-
Christian Rohmann
-
Pritha Srivastava