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
