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
