[ 
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332589#comment-17332589
 ] 

Siddharth Wagle edited comment on HDDS-4944 at 4/26/21, 4:53 PM:
-----------------------------------------------------------------

>From what is proposed here, I see multi-tenancy as a way to put a user or a 
>group of users in a chroot jail of a volume. Allow S3 users to access not just 
>S3V. Add a tenant level aggregation and reporting based on volume/volumes that 
>belong to a tenant for the users in that tenancy.

It is not a path prefix, so adding this should be relatively easier and I think 
we should be able to figure out from user context what tenancy they belong to, 
so the <tenant-name>:<bucket-name> should not be required IMO.

An external STS might be a good idea anyway, outside of tenancy discussion 
because right now even if a user is not a valid LDAP user, they can access 
Ozone using S3 secret. But will STS solve this is open to interpretation, it 
may make it easier to have secret rotation, etc, not take the problem go away 
but provide some way to make it easier to mitigate.




was (Author: swagle):
>From what is proposed here, I see multi-tenancy as a way to put a user or a 
>group of users in a chroot jail of a volume. Allow S3 users to access not just 
>S3V. Add a tenant level aggregation and reporting based on volume/volumes that 
>belong to a tenant for the users in that tenancy.

It is not a path prefix, so adding this should be relatively easier and I think 
we should be able to figure out from user context what tenancy they belong to, 
so the <tenant-name>:<bucket-name> should not be required IMO.

An external STS might be a good idea anyway, outside of tenancy discussion 
because right now even if a user is not a valid LDAP user, they can access 
Ozone using S3 secret. But will STS solve this is open to interpretation, it 
may make it easier to have secret rotation, etc, not take the problem go away 
but provide some way to make it easier to manage.



> 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, uml_multitenant_interface_design.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]

Reply via email to