[
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318326#comment-17318326
]
Prashant Pogde edited comment on HDDS-4944 at 4/10/21, 12:49 AM:
-----------------------------------------------------------------
@ [~elek] Thank you for going through the proposal and comments. Please find
comments inline
>> As I wrote earlier, still I am not convinced why do we combine the
>> multi-tenancy feature with the kerberos-independent secret
>> management. ....
I think we have some disconnect here. We are not proposing any new
authentication-scheme/secret-managment-scheme here. This proposal would work
with the existing authentication mechanism that we already have in Ozone. At
the same time, this proposal would not limit/restrict any future support in
Ozone for any new authentication scheme.
>>I am not sure about this one. I think it's rather confusing as we use Hadoop
>>UGI. We should have a different UGI name for different
>> identities to have proper ACL handling and audit logging. Which means that
>> the two users should be different (with multi-tenant
>> abstraction it means that we need to add the tenancy to the username). I
>> would rather say that the AWS S3 compatible access key
>> id should be as randomized as in AWS (and independent of UIG username) and
>> we don't need to care about this one.
I believe we are talking about specific implementation of the requirements
here. I think we can support both randomized accessId(AWS) as well as username
that encapsulates tenant ID (Ceph). Some of the users in the industry that we
talked to, will use Ceph convention when sending S3 API requests.
>> The question here: do we need to add this complex feature (full group
>> management) to Ozone?
We do not have to introduce "group management" in ozone. We can also use any
external service for group management.
>> Is it possible with dedicating volumes to sub-organizations?
I think we are on the same page about leveraging volumes to provide
bucket-namespace for Tenants.
>> For me, this is the most important part. We already have a volume notion for
>> bucket-namespace isolation, but this is missing from >> our current
>> offering. This requires a full user/group management interface.
>> ........
We do not have to implement group-management in Ozone. We can also use external
engines like Apache-Ranger to do this.
I think we are on the same page here wrt
- Improving the current s3 credential handling to make the credentials
Kerberos independent
- Using external service like Ranger for group/policy-Management
Other than this, We seem to have disagreement on the abstractions terminology
part. I very humbly believe that abstractions in the product should be closer
to user notions or terminology that is widely adopted in the industry rather
than using disconnected terminology. We already have an example of using
"ozone containers". What the ozone developer community thinks of a "container"
is very different from what users or people outside the community would
typically think.
If we have a product that can support multi-tenant environment, our terminology
should reflect that, and make it easier to connect with our user base with it.
was (Author: ppogde):
@ [~elek] Thank you for going through the proposal and comments. Please find
comments inline
>> As I wrote earlier, still I am not convinced why do we combine the
>> multi-tenancy feature with the kerberos-independent secret
>> management. ....
I think we have some disconnect here. We are not proposing any new
authentication-scheme/secret-managment-scheme here. This proposal would work
with the existing authentication mechanism that we already have in Ozone. At
the same time, this proposal would not limit/restrict any future support in
Ozone for any new authentication scheme.
>>I am not sure about this one. I think it's rather confusing as we use Hadoop
>>UGI. We should have a different UGI name for different
>> identities to have proper ACL handling and audit logging. Which means that
>> the two users should be different (with multi-tenant
>> abstraction it means that we need to add the tenancy to the username). I
>> would rather say that the AWS S3 compatible access key
>> id should be as randomized as in AWS (and independent of UIG username) and
>> we don't need to care about this one.
I believe we are talking about specific implementation of the requirements
here. I think we can support both randomized accessId(AWS) as well as username
that encapsulates tenant ID (Ceph). Some of the customers that we talked to,
will use Ceph convention when sending S3 API requests.
>> The question here: do we need to add this complex feature (full group
>> management) to Ozone?
We do not have to introduce "group management" in ozone. We can also use any
external service for group management.
>> Is it possible with dedicating volumes to sub-organizations?
I think we are on the same page about leveraging volumes to provide
bucket-namespace for Tenants.
>> For me, this is the most important part. We already have a volume notion for
>> bucket-namespace isolation, but this is missing from >> our current
>> offering. This requires a full user/group management interface.
>> ........
We do not have to implement group-management in Ozone. We can also use external
engines like Apache-Ranger to do this.
I think we are on the same page here wrt
- Improving the current s3 credential handling to make the credentials
Kerberos independent
- Using external service like Ranger for group/policy-Management
Other than this, We seem to have disagreement on the abstractions terminology
part. I very humbly believe that abstractions in the product should be closer
to customer notions or terminology that is widely adopted in the industry
rather than using disconnected terminology. We already have an example of
using "ozone containers". What the ozone developer community thinks of a
"container" is very different from what customers or people outside the
community would typically think.
If we have a product that can support multi-tenant environment, our terminology
should reflect that, and make it easier to connect with our user/customer base
with it.
> 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]
