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