[
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17319187#comment-17319187
]
Marton Elek commented on HDDS-4944:
-----------------------------------
Thanks the answers [~ppogde]
bq. 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.
Yes, we may have a disconnect because my concern was not this. It's not about a
fear if we can add a new authentication scheme later or not. It's about the
fear to add unnecessary complexity right now. And my suggestion is to separate
the two questions from each other is independent (IMHO)
bq. I believe we are talking about specific implementation of the requirements
here...
We are talking about user mapping. There is an AWS accessKey id in Ozone which
is mapped to a Hadoop UGI. Today we use kerberos id as an AWS key id, and it's
used as a Hadoop UGI string.
1. AWS accessKey id should always be unique system-wide. We can use randomized
key names, or we can add some tenant prefixes, but at the end of the day we
will have different "accessKey id"-s. None of the approaches support using
exactly the same "accessKey id" twice in two different roles. Therefore, it's
not a forced account namespace isolation, but some good technical tricks to
avoid name collisions.
2. The next question: how do we map the AWS specific string to a Hadoop UGI
string. We need to use a string name eventually which may or may not be
conflicted with users from other sources (like kerberos).
bq. We do not have to introduce "group management" in ozone. We can also use
any external service for group management.
I think we either use "group management" differently or I totally misunderstood
something. When we have admin and super-admins which can manage either users
or credentials in tenant/groups, it seems to be a user/group management for me.
Can you please clarify the role of Ranger here? (Which ranger calls are used?
Where are the tenant groups are stored? And what about the non-ranger use
cases?)
> 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.
I understand this argument, and it can be definitely an argument on one side.
Containers are confusing names, no doubt.
But I am not arguing to avoid the usage of "tenant" in Ozone context. I am
arguing that we already have tenants. And the only thing what we should do is
calling volume as tenant. We have tenant / bucket / key structure.
(Ok, I simplified my argument just to show my thinking. I agreed that even with
this approach we may need some small changes. And my main concerns were that
the available options are not compared, and I am not convinced that a new (!!!)
abstraction layer is the best way to move forward instead of re-using an
existing abstraction layer)
One more thing: I understand your argument that it can be confusing to use
different words (like volume) instead of tenancy. But there is another side of
the story: using both volume and tenancy layer (especially with non 1:1
relation between tenants and volumes) can make the full administration more
complex. Where should I set the quotas? On volume level? On tenant level? I
think it's better to have limit-number of well-scoped abstractions, but I am
fine with using tenancy in the context of abstraction (volumes are separation
for tenants...)
> 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]
