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
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.
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.
- 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
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?
Show replies by date