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
