(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? _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
