Can multiple accounts have the same tenant? Or is tenant a 1-to-1 with an account?

it's fine for several accounts to share a tenant name, the same way accounts can share the global (empty tenant) namespace

for ease of understanding, we should clarify the implications of accounts sharing a tenant and maybe why someone would do it--iirc, @mmgaggle has described the ability to maintain a hierarchy of accounts in aws, and I don't think we're bringing all that detail in (e.g.)

we should clarify the implications of accounts sharing a tenant and maybe why someone would do it

you'd use multiple tenants if you want namespace isolation, and multiple accounts if you want isolation of user/role/policy management

if you want a global dns namespace like aws, put all accounts in the global empty-tenant namespace

iirc, @mmgaggle has described the ability to maintain a hierarchy of accounts in aws, and I don't think we're bringing all that detail in (e.g.)

interested to hear more about that requirement and how it relates to tenant namespacing. naively, it sounds like we'd just want an account to have an optional 'parent' account that it can inherit some policy from

iirc, @mmgaggle has described the ability to maintain a hierarchy of accounts in aws, and I don't think we're bringing all that detail in (e.g.)

interested to hear more about that requirement and how it relates to tenant namespacing. naively, it sounds like we'd just want an account to have an optional 'parent' account that it can inherit some policy from

in aws, it's the AWS Organizations API that's responsible for the grouping of related accounts and the management of policy like service control policy:

https://docs.aws.amazon.com/organizations/latest/APIReference/Welcome.html
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

maybe we could find some subset of that Organizations API that would accomplish our goals here, instead of adding special custom behaviors to the accounts themselves?

I agree @cbodley; investigating, if using a subset of the OUs API could help us introduce a similar concept as to what AWS does with Control Tower, specifically with what they call preventive controls, which looks like it's enforcing SCPs at the OU level , perhaps within organizations, we could introduce templates for different policy/configurations and rules for enforcing them.

this scaling discussion drops down to details of the RADOS implementation, but as of today, I think we need to also consider alternate stores; are there any aspects of this design that aren't trivially covered by zipper abstractions and compatible with dbstore?

are there any aspects of this design that aren't trivially covered by zipper abstractions and compatible with dbstore?

nope! sal has interfaces to read/write the quota limits on buckets/users, and a Bucket::check_quota() that's responsible for quota enforcement. backends can implement the quota accounting for that however they choose

this design goes into details of the rados backend because it's the only one that implements quota

Hi, I do think that IAM groups can help when implementing/operating IAM accounts at-scale, as an operator/admin I can configure, all the required policies in IAM groups, and then add the IAM users to the different groups as needed, instead of applying policy per IAM user, so it could come in handy.

the iam rest apis for Group look very similar to User and Role, so we should be able to share lots of code there. then we'd need AddUserToGroup/RemoveUserFromGroup actions to manage group memberships in RGWUserInfo, parse group principals in iam policy documents, and match group principals to the authenticated user. past that, i'm not sure what else is missing

i don't think group support needs to be part of the 'mvp' for accounts, but we can track the design here for followup work

Yes, I agree @cbodley , no need for groups in the MVP

i did end up implementing the Group and GroupPolicy apis in #54333

@cbodley one question here, just to verify if I'm getting this right, we don't need to rely on tenants to be able to have the same user name on different accounts right?,for example: if you have two accounts, you can have users with the same name in each, but there is a single bucket namespace for everyone(both accounts will belong to the default tenant).

essentially yes, account A can have a UserName=foo and account B can have a different user with UserName=foo. if account A and B belong to the same tenant, their users will share a common bucket namespace

however, the iam User APIs map UserName to RGWUserInfo::display_name instead of RGWUserInfo::user_id. those variables correspond to the --display-name and --uid arguments to radosgw-admin user create

it's the user_ids that we require to be unique within the tenant, and that still holds for account users - we just generate a random uuid like '550e8400-e29b-41d4-a716-446655440000' for unique user_ids

user ARNs also look different for account users: arn:aws:iam::{account_id}:user/{display_name} vs arn:aws:iam::{tenant}:user/{user_id}

so for a user in account RGW12345678901234567, an iam GetUser response would look something like this:

    <User>
      <UserId>550e8400-e29b-41d4-a716-446655440000</UserId>
      <Path>/</Path>
      <UserName>foo</UserName>
      <Arn>arn:aws:iam::RGW12345678901234567:user/foo</Arn>
      <CreateDate>2013-10-02T17:01:44Z</CreateDate>
    </User>

Thanks for the explanation, that is clear now.

@cbodley could it also be a good idea to add the OIDC Provider as a resource with an ownership link to the account?.

thanks, i hadn't planned for this yet. Topic metadata also needs to be adapted for account ownership. i added these to the TODO list in #54333

Thanks

@cbodley : existing rgw users have certain permissions by default like CreateBucket etc. What happens to those permissions when they are added as an iam user to an account?

Also what happens to policy evaluation logic in case existing users/ roles are grouped into multiple accounts inside a tenant and then if an existing resource policy (bucket policy) has ::user/* set as Principal - will this allow all users of all accounts belonging to that tenant, to access that resource? or are we going to expect the end users to update the policies if they plan to add existing users/roles to accounts?

@cbodley : existing rgw users have certain permissions by default like CreateBucket etc. What happens to those permissions when they are added as an iam user to an account?

they're lost. when you adopt users into an account, you also need to add some identity policy

existing resource policy (bucket policy) has ::user/* set as Principal

you can find the updated LocalApplier::is_identity() in #54333

currently, account users will match the following principals:

• wildcard principal *
• user principals arn:aws:iam::{account_id}:user/{path}{display_name} or arn:aws:iam::{account_id}:user/*
• account principals arn:aws:iam::{account_id}:root or {account_id}
• account principals arn:aws:iam::{tenant}:root or {tenant}

it probably makes sense to add matching for user principals like arn:aws:iam::{tenant}:user/{user_id} and arn:aws:iam::{tenant}:user/* for backward compatibility with existing resource policy

the question was specifically for tenant-id/user/*, tenant-id was in angle brackets <> and didn't show up in the comment.

s/APIs. t/APIs. T/

s/end-users/end users/