Re: rfc: Accounts in RGW

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(oops, i had cc'ed this to the old ceph-users list)

On Wed, Jun 15, 2022 at 1:56 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
>
> On Mon, May 11, 2020 at 10:20 AM Abhishek Lekshmanan <abhishek@xxxxxxxx> wrote:
> >
> >
> > The basic premise is for an account to be a container for users, and
> > also related functionality like roles & groups. This would converge
> > similar to the AWS concept of an account, where the AWS account can
> > further create iam users/roles or groups. Every account can have a root
> > user or user(s) with permissions to administer creation of users and
> > allot quotas within an account. These can be implemented with a new
> > account cap. IAM set of apis already have a huge subset of functionality
> > to summarize accounts and inspect/create users/roles or groups. Every
> > account would also store the membership of its users/groups and roles,
> > (similar to user's buckets) though we'd ideally limit to < 10k
> > users/roles or groups per account.
> >
> > In order to deal with the currently used tenants which namespace
> > buckets, but also currently stand in for the account id in the policy
> > language & ARNs, we'd have a tenant_id attribute in the account, which
> > if set will prevent cross tenant users being added. Though this is not
> > enforced when the tenant id isn't set, accounts without this field set
> > can potentially add users across tenants, so this is one of the cases
> > where we expect the account owner to know what they are doing.
> > We'd transition away from <tenant>:<user> in the Policy principal to
> > <account-id>:<user>, so if users with different tenants are in the same account
> > we'd expect the user to change their policies to reuse the account ids.
> >
> > In terms of regular operations IO costs, the user info would have an account id
> > attribute, and if non empty we'd have to read the Account root user policies and
> > /or public access configuration, though other attributes like list of users/roles
> > and groups would only be read for necessary IAM/admin apis.
> >
> > Quotas
> > ~~~~~~
> > For quotas we can implement one of the following ways
> > - a user_bytes/buckets quota, which would be alloted to every user
> > - a total account quota, in which case it is the responsibility of the account
> >   user to allot a quota upon user creation
> >
> > Though for operations themselves it is th user quota that comes into play.
> >
> > APIs
> > ~~~~
> > - creating an account itself should be available via the admin tooling/apis
> > - Ideally creation of a root user under an account would still have to be
> >   explicitly, though we could consider adding this to the account creation
> >   process itself to simplify things.
> > - For further user creation and management, we could start implementing to the
> >   iam set of apis in the future, though currently we already have admin apis for
> >   user creation and the like, and we could allow the user with account caps to
> >   do these operations
> >
> > Deviations
> > ~~~~~~~~~~
> > Some apis like list buckets in AWS list all the buckets in the user account and
> > not the specific iam user, we'd probably still list only the user buckets,
> > though we could consider this for the account root user.
> >
> > Wrt to the openstack swift apis, we'd still keep the current user_id -> swift
> > account id mapping, so no breakage is expected wrt end user apis, so the
> > account stats and related apis would be similar to the older version where
> > it is still user's summary that is displayed
> >
> > Comments on if this is the right direction?
> >
> > --
> > Abhishek
> > _______________________________________________
> > Dev mailing list -- dev@xxxxxxx
> > To unsubscribe send an email to dev-leave@xxxxxxx
> >
>
> this project has been revived in
> https://github.com/ceph/ceph/pull/46373 and we've been talking through
> the design in our weekly refactoring meeting
>
> Abhishek shared a good summary of the design above. the only major
> changes we've made are in its interaction with swift tenants:
> - accounts will be strictly namespaced by tenant, so an account can't
> mix users from different tenants
> - add a unique account ID, separate from the account name, for use in
> IAM policy. use a specific, documented format to disambiguate account
> IDs from tenant names
>
> the account features we're planning to start with are:
> - radosgw-admin commands and /admin/ APIs to add/remove/list the users
> and roles under an account
> - support for IAM principals like ACCOUNTID/username,
> ACCOUNTID/rolename and ACCOUNTID/* in addition to tenant/...
> - ListAllMyBuckets lists all buckets under the user's account, not
> only those owned by the user
> - account quotas that limit objects/bytes, on top of existing user/bucket quotas
>
> eventually we'd like to add:
> - IAM APIs for account and user management by 'account root users'
> without global admin caps
> - support for groups under account
>
> i'd love to hear feedback from the community - what kind of account
> functionality would you most like to see?

_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux