Re: [ceph-users] Re: rfc: Accounts in RGW

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

 



On Thu, Jun 16, 2022 at 9:09 AM Daniel Gryniewicz <dang@xxxxxxxxxx> wrote:
>
> On 6/15/22 14:06, Casey Bodley wrote:
> > (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
>
> A thought just occurred to me.  The impetus of this work was to have
> tenant quota.  Since we're not having one account/tenant anymore, how do
> we get tenant quota out of this work?

you'd still have the option to create one account per tenant for
tenant-wide quota management. but you also have the option to make
them more granular

>
>
> >>
> >> 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
> >
>

_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux