[
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318220#comment-17318220
]
Prashant Pogde edited comment on HDDS-4944 at 4/10/21, 12:47 AM:
-----------------------------------------------------------------
Thank you [~pifta] for comments. There are lot of questions here and hence the
answer would be lengthy :) please find answers inline
> A few problems that I see:
- > according to requirement 2/h/v. tenant admins should be able to see modify
and delete their tenant's users' data. This implies > possibly unwanted cross
tenant access for tenant admins in tenants where there is a user who accesses
an other tenant's > >resources
I think this is misunderstood here. Tenant Admins are restricted to their
tenancies only. They can not access any other tenants bucket/keys/users etc by
default. For example, Tenant Admin "A" can not access any of the resources in
Tenant "B" by default.
A cross Tenancy access authorization is given *explicitly with full awareness
of consequences by the corresponding tenant admins.* E.g. a Tenant Admin "A"
can allow access to a specific bucket "A/b1" to Tenant user "B/u1" by setting
up a bucket policy for "A/b1". There are no unwanted accesses here. Also just
because Tenant user "B/u1" has access to bucket "A/b1", it does not give
automatic access by "B/Admin" to bucket "A/b1".
>> if a tenant admin can allow access for a user in an other tenant, that would
>> mean that a tenant admin can access an other tenant's >> user object(s)
No this is not possible like explained above. A tenant admin gets superuser
privileges only within his tenancy. Not in another tenancy.
>> if a user from tenant a can have write access to tenant b, then tenant b QoS
>> quotas will be affected by a user in tenant a, also tenant
>> a quotas should aggregate usage of the user in tenant b which makes
>> enforcement and calculation of these way too heavy, or very >> limited and
>> exploitable
A typical use case would be, allowing Tenant user "B/U1", temporary read access
to a bucket "A/b1" owned by tenant "A". And such a policy would be created by
Tenant Admin "A" because they are the owners for all resources consumed in
Tenancy "A". Now, Its a very possible use case, if Tenant A admin wants to give
write access to user Tenant B/U1 in A's bucketNamespace. But this will be
explicitly setup by "A" and "A"'s admin would be aware of quota consequences.
The proposal actually speaks of quota feature for both BucketNamsepace as well
as AccountNamespace. So for "A", its possible to see the
A) bucketNamespace Usage \{regardless of who(users) wrote to the buckets and
who the owner for the keys is}. Given the fact that we are leveraging "Volumes"
to represent bucketNamespace, this is as simple as checking Volume usage and
comparing it against quota set on the volumes.
B) AccountNamespace Usage \{regardless of where or which bucketNamespaces the
keys were created in}. This could be as simple as aggregating the resources
usage for each user that belongs to the AccountNamespace. "A", also comparing
such a usage against any AccountNamespace quota.
Any such usage aggregation/quota enforcement can be done online or lazily as
part of recon task.The proposal does not talk about specific implementation but
a mechanism to address the possible use cases.
>> it is a problem to figure out how to isolate comfortably the access policies
>> and tie it to a user, when the user exists in one tenant
>> only, but is has to be harmonized with general policies in the other tenant,
>> not to mention groups/roles associated to the user that
>> might exists just in one tenant, and does not have a real meaning in the
>> other
I am not sure I get the question here. Can you please rephrase ? Users are
globally visible just like active directory where you can see users across
different departments within an organization.
>> applying different password policies is really complex, especially if user
>> lifecycle events apply to tenant users differently tenant by
>> tenant and has different enforcement rules... (what happens if one tenant
>> uses kerberos auth, and does not care much about aws
>> keys, while the other uses aws style access exclusively... who can
>> administer this for the user, where the user will configure the
>> different access patterns? etc.)
I think this is misunderstood. This Multitenancy proposal does not talk about
different password policies for different tenants or any such thing here. User
Authentication is independent of Multi-Tenancy. A user is authenticated based
on the credentials they present to Ozone and it should not have anything to do
with Multi-tenenacy.
> I would like to clear one question related to super-admins, I believe we
> should explicitly declare that these type of admins should >
> not have access to any tenant data on their own, but are just have the
> ability to administer tenant's, tenant admins, and QoS limit
> enforcements on tenants, and can see the list of tenants the QoS usage
> statistics of tenants, and maybe the list of tenant users, but
> they should not have access to tenant's data/metadata.
The proposed system here achieves AccessControl with the means of
"bucket/Volume" policies which will be either default system created or
explicitly created by the Users and Tenant-Admins. It is always possible to add
"Allow/Deny" policies based on the use cases.
>> Also I think it would be beneficial to make it clear that we think about the
>> volumes as the abstraction provides bucket namespace
>> isolation, and we do not want to develop an other abstraction on top of it,
>> though for ease of use we might introduce aliases that
>> reflect multi-tenancy terminology better.
I think it is not a good idea to introduce abstractions that conflict with
generic industry understating. As an example, we have "Containers" and
explaining this abstraction to anyone who is not in Ozone developer community
has been a challenge. The problem is even after you explain/force and folks
understand it for a while, they go back their original notions of these
terminologies after a while.
"Tenant" is a well known industrywide abstraction to isolate resource in any
system and, very humbly, I think we should use the right abstractions that
resonate with our users rather than to force our developement centric notions
on the users.
>>There is one problem, 3/c in the features and limitations section, global
>>bucket namespace... If we have a well separated account
>> namespace isolation that does not get in our way we can use it on top of one
>> volume probably.
I am not sure I understand what is the disconnect here. Can you please
elaborate ?
>> I am full on with Marton that we should separate the problem to more parts
>> and discuss each of this separately to figure out the
>> gaps, and possible implementation approaches with benefits and drawbacks.
>> Marton talked about bucket and account namespace
>> isolation, I would like to add to that list. I would cut out the QoS, and
>> tenant in tenant (hierarchy of tenants) related things.
This proposal is already separating out BucketNamespace and AccountNamespace
requirements. The proposal is already talking about leveraging the volume
abstraction to meet the requirements. I don't see how things that you/Marton
are suggesting are different. Perhaps we are saying the same thing.
>> Account namespace isolation: I agree with Mrton, let's try to think about
>> this as an addon, that brings in complexity, I think maybe
>> the best is to have Hadoop style SIMPLE auth as the default, and even
>> kerberos auth I belive should go into a plugin >>
>> implementation, with that for this refactor we already have 2 authentication
>> styles, we can add SAML, we can add oAuth, we can
>> add any other authentication mode
Regarding the AccountNamespace isolation, It's just a way of grouping users at
a high level and ability to treat these groups as an isolation unit. I think it
should not be mixed/confused with authentication schemes. This proposal does
not limit or extend any existing authentication scheme that we have in Ozone.
>> QoS: I think about this similarly to authentication, authorization or even
>> auditing... This
.....
I think the user ask here is the ability to isolate users/resources so that
quotas/QOS/usage-consolidation and enforcements can be placed based on these
isolation groups. It's not an immediate ask and this can be built over time.
There could be lazy implementation modules (e.g. recon) or an
inline-implementation module. I think we are on the same page about this being
a pluggable module.
Overall I think we are pretty much saying the same things except for some
misunderstandings. About the abstractions, I believe, we should have the right
terminology that *resonates with our users* rather than forcing our
abstractions on them as explained above.
I have setup a call On Monday 4/12 10 am PST to discuss this and avoid any
mixup/confusion on the proposal.
[https://cloudera.zoom.us/j/95551894948]
was (Author: ppogde):
Thank you [~pifta] for comments. There are lot of questions here and hence the
answer would be lengthy :) please find answers inline
> A few problems that I see:
- > according to requirement 2/h/v. tenant admins should be able to see modify
and delete their tenant's users' data. This implies > possibly unwanted cross
tenant access for tenant admins in tenants where there is a user who accesses
an other tenant's > >resources
I think this is misunderstood here. Tenant Admins are restricted to their
tenancies only. They can not access any other tenants bucket/keys/users etc by
default. For example, Tenant Admin "A" can not access any of the resources in
Tenant "B" by default.
A cross Tenancy access authorization is given *explicitly with full awareness
of consequences by the corresponding tenant admins.* E.g. a Tenant Admin "A"
can allow access to a specific bucket "A/b1" to Tenant user "B/u1" by setting
up a bucket policy for "A/b1". There are no unwanted accesses here. Also just
because Tenant user "B/u1" has access to bucket "A/b1", it does not give
automatic access by "B/Admin" to bucket "A/b1".
>> if a tenant admin can allow access for a user in an other tenant, that would
>> mean that a tenant admin can access an other tenant's >> user object(s)
No this is not possible like explained above. A tenant admin gets superuser
privileges only within his tenancy. Not in another tenancy.
>> if a user from tenant a can have write access to tenant b, then tenant b QoS
>> quotas will be affected by a user in tenant a, also tenant
>> a quotas should aggregate usage of the user in tenant b which makes
>> enforcement and calculation of these way too heavy, or very >> limited and
>> exploitable
A typical use case would be, allowing Tenant user "B/U1", temporary read access
to a bucket "A/b1" owned by tenant "A". And such a policy would be created by
Tenant Admin "A" because they are the owners for all resources consumed in
Tenancy "A". Now, Its a very possible use case, if Tenant A admin wants to give
write access to user Tenant B/U1 in A's bucketNamespace. But this will be
explicitly setup by "A" and "A"'s admin would be aware of quota consequences.
The proposal actually speaks of quota feature for both BucketNamsepace as well
as AccountNamespace. So for "A", its possible to see the
A) bucketNamespace Usage \{regardless of who(users) wrote to the buckets and
who the owner for the keys is}. Given the fact that we are leveraging "Volumes"
to represent bucketNamespace, this is as simple as checking Volume usage and
comparing it against quota set on the volumes.
B) AccountNamespace Usage \{regardless of where or which bucketNamespaces the
keys were created in}. This could be as simple as aggregating the resources
usage for each user that belongs to the AccountNamespace. "A", also comparing
such a usage against any AccountNamespace quota.
Any such usage aggregation/quota enforcement can be done online or lazily as
part of recon task.The proposal does not talk about specific implementation but
a mechanism to address the possible use cases.
>> it is a problem to figure out how to isolate comfortably the access policies
>> and tie it to a user, when the user exists in one tenant
>> only, but is has to be harmonized with general policies in the other tenant,
>> not to mention groups/roles associated to the user that
>> might exists just in one tenant, and does not have a real meaning in the
>> other
I am not sure I get the question here. Can you please rephrase ? Users are
globally visible just like active directory where you can see users across
different departments within an organization.
>> applying different password policies is really complex, especially if user
>> lifecycle events apply to tenant users differently tenant by
>> tenant and has different enforcement rules... (what happens if one tenant
>> uses kerberos auth, and does not care much about aws
>> keys, while the other uses aws style access exclusively... who can
>> administer this for the user, where the user will configure the
>> different access patterns? etc.)
I think this is misunderstood. This Multitenancy proposal does not talk about
different password policies for different tenants or any such thing here. User
Authentication is independent of Multi-Tenancy. A user is authenticated based
on the credentials they present to Ozone and it should not have anything to do
with Multi-tenenacy.
> I would like to clear one question related to super-admins, I believe we
> should explicitly declare that these type of admins should >
> not have access to any tenant data on their own, but are just have the
> ability to administer tenant's, tenant admins, and QoS limit
> enforcements on tenants, and can see the list of tenants the QoS usage
> statistics of tenants, and maybe the list of tenant users, but
> they should not have access to tenant's data/metadata.
The proposed system here achieves AccessControl with the means of
"bucket/Volume" policies which will be either default system created or
explicitly created by the Users and Tenant-Admins. It is always possible to add
"Allow/Deny" policies based on the use cases.
>> Also I think it would be beneficial to make it clear that we think about the
>> volumes as the abstraction provides bucket namespace
>> isolation, and we do not want to develop an other abstraction on top of it,
>> though for ease of use we might introduce aliases that
>> reflect multi-tenancy terminology better.
I think it is not a good idea to introduce abstractions that conflict with
generic industry understating. As an example, we have "Containers" and
explaining this abstraction to anyone who is not in Ozone developer community
has been a challenge. The problem is even after you explain/force and folks
understand it for a while, they go back their original notions of these
terminologies after a while.
"Tenant" is a well known industrywide abstraction to isolate resource in any
system and, very humbly, I think we should use the right abstractions that
resonate with our customers rather than to force our developement centric
notions on the customers.
>>There is one problem, 3/c in the features and limitations section, global
>>bucket namespace... If we have a well separated account
>> namespace isolation that does not get in our way we can use it on top of one
>> volume probably.
I am not sure I understand what is the disconnect here. Can you please
elaborate ?
>> I am full on with Marton that we should separate the problem to more parts
>> and discuss each of this separately to figure out the
>> gaps, and possible implementation approaches with benefits and drawbacks.
>> Marton talked about bucket and account namespace
>> isolation, I would like to add to that list. I would cut out the QoS, and
>> tenant in tenant (hierarchy of tenants) related things.
This proposal is already separating out BucketNamespace and AccountNamespace
requirements. The proposal is already talking about leveraging the volume
abstraction to meet the requirements. I don't see how things that you/Marton
are suggesting are different. Perhaps we are saying the same thing.
>> Account namespace isolation: I agree with Mrton, let's try to think about
>> this as an addon, that brings in complexity, I think maybe
>> the best is to have Hadoop style SIMPLE auth as the default, and even
>> kerberos auth I belive should go into a plugin >>
>> implementation, with that for this refactor we already have 2 authentication
>> styles, we can add SAML, we can add oAuth, we can
>> add any other authentication mode
Regarding the AccountNamespace isolation, It's just a way of grouping users at
a high level and ability to treat these groups as an isolation unit. I think it
should not be mixed/confused with authentication schemes. This proposal does
not limit or extend any existing authentication scheme that we have in Ozone.
>> QoS: I think about this similarly to authentication, authorization or even
>> auditing... This
.....
I think the customer ask here is the ability to isolate users/resources so that
quotas/QOS/usage-consolidation and enforcements can be placed based on these
isolation groups. It's not an immediate ask and this can be built over time.
There could be lazy implementation modules (e.g. recon) or an
inline-implementation module. I think we are on the same page about this being
a pluggable module.
Overall I think we are pretty much saying the same things except for some
misunderstandings. About the abstractions, I believe, we should have the right
terminology that *resonates with our customers* rather than forcing our
abstractions on them as explained above.
I have setup a call On Monday 4/12 10 am PST to discuss this and avoid any
mixup/confusion on the proposal.
https://cloudera.zoom.us/j/95551894948
> Multi-Tenant Support in Ozone
> -----------------------------
>
> Key: HDDS-4944
> URL: https://issues.apache.org/jira/browse/HDDS-4944
> Project: Apache Ozone
> Issue Type: New Feature
> Components: Ozone CLI, Ozone Datanode, Ozone Manager, Ozone Recon,
> S3, SCM, Security
> Affects Versions: 1.2.0
> Reporter: Prashant Pogde
> Assignee: Prashant Pogde
> Priority: Major
> Labels: pull-request-available
> Attachments: Apache-S3-compatible-Multi-Tenant-Ozone-short.pdf.gz,
> Ozone MultiTenant Feature _ Requirements and Abstractions-3.pdf, Ozone,
> Multi-tenancy, S3, Kerberos....pdf, UseCaseAWSCompatibility.pdf,
> UseCaseCephCompatibility.pdf, UseCaseConfigureMultiTenancy.png,
> UseCaseCurrentOzoneS3BackwardCompatibility.pdf, VariousActorsInteractions.png
>
>
> This Jira will be used to track a new feature for Multi-Tenant support in
> Ozone. Initially Multi-Tenant feature would be limited to ozone-users
> accessing Ozone over S3 interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
