[
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17307809#comment-17307809
]
Marton Elek commented on HDDS-4944:
-----------------------------------
Thanks the answers [~ppogde].
bq. 2. No, Ozone will not implement group/roles in OM. Users need not exist in
Apache Ranger
Why do we need Ranger here in this case? I don't see how is it required for
bucket-namespace or account-namepsace separation. Authorization seems to be an
orthogonal question.
bq. 4. The current proposal is for managing S3 users with Multi-Tenancy because
S3-users are completely internally managed by Ozone
Yes, this is about multi-tenancy. But creating kerberos independent S3
credentials with an admin user is independent of the multi-tenancy. It can be
implemented without any multi-tenancy, therefore it seems to be more logical
(for me) to separate the questions to clearly communicate what is required for
account-/bucket-namespace isolation and what is required for better S3 secret
management.
bq. 3. This is Multi-Tenant management in Ozone... Once we have multi-tenancy,
we do need to classify users as belonging to one or the other tenant
Yes, I got it, I think I got it, it's one way to provide some
account-namespace isolation. For me, the description and comparison with
alternatives are still missing. Especially when existing volume abstraction is
better used instead (!) of new tenant abstraction.
As we discussed during the community meeting it would be great to collect
requirements and possible requirements. I would prefer to do it without using
any "tenant" abstraction.
For example:
* Users of different organization unit may need different view of bucket list
(bucket-namespace isolation)
* Management of AWS secrets should be possible to delegate to non-admin users
for specific user groups. (one part of account-namespace isolation, as fas as I
understood from the community meeting we wouldn't like to provide full
separation, it would be possible to access multiple account-namespaces with the
same account...)
Once we have a list of requirement (with priorities) it would be easier to
discuss how existing abstractions can be re-used and what kind of new
abstractions are required and how can they be compatible with the current
architecture and the future visions...
> 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, 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]
