You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Mikhail Pochatkin (Jira)" <ji...@apache.org> on 2023/03/01 13:33:00 UTC

[jira] [Updated] (HDDS-8050) Create HTTP endpoint to access S3 secret via Kerberos auth

     [ https://issues.apache.org/jira/browse/HDDS-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Pochatkin updated HDDS-8050:
------------------------------------
    Description: 
There is currently only one way to generate an S3 secret for a user, and that is the S3 namespace in the ozone binary script.

With this approach, the user must have access to the cluster/node directly or provide it to the cluster administrator. There are two problems here
1. The user may not have access to the cluster machine, for example, in the case of a service cluster.
2. If the administrator generates an S3 secret using the ozone script, then this secret will be completed and, as a result, all user data. Some environments and companies may have security restrictions on this sensitive information for certain third parties, such as the cluster administrator.

Here we have no way to automatically and securely generate an S3 secret. 
As solution I have option to create additional S3 secret HTTP server on S3 Gateway witch will have enable Kerberos HTTP authentication for two endpoint. First one is generate secret, and second one is revoke secret.

These endpoint will generate S3 secret for user who authorized via Kerberos and provide kerberos token via REST call (for example via curl --negotiate) and return it. In this case no one except user may generate and revoke secret for itself, especially with correct combination with ozone.s3.administrators property settings.

 

This S3 security server should have separate configuration properties and may be enabled only in case when node env has Kerberos. By default this server will be disable until configuration will be presented.

  was:
There is currently only one way to generate an S3 secret for a user, and that is the S3 namespace in the ozone binary script.

With this approach, the user must have access to the cluster/node directly or provide it to the cluster administrator. There are two problems here
1. The user may not have access to the cluster machine, for example, in the case of a service cluster.
2. If the administrator generates an S3 secret using the ozone script, then this secret will be completed and, as a result, all user data. Some environments and companies may have security restrictions on this sensitive information for certain third parties, such as the cluster administrator.

Here we have no way to automatically and securely generate an S3 secret. 
As solution I have option to create additional S3 secret HTTP server on S3 Gateway witch will have enable Kerberos HTTP authentication for two endpoint. First one is generate secret, and second one is revoke secret.

These endpoint will generate S3 secret for user who authorized via Kerberos and provide kerberos token via REST call (for example via curl --negotiate) and return it. In this case no one except user may generate and revoke secret for itself, especially with correct combination with ozone.s3.administrators property settings.


> Create HTTP endpoint to access S3 secret via Kerberos auth
> ----------------------------------------------------------
>
>                 Key: HDDS-8050
>                 URL: https://issues.apache.org/jira/browse/HDDS-8050
>             Project: Apache Ozone
>          Issue Type: Improvement
>          Components: S3
>    Affects Versions: 1.4.0
>            Reporter: Mikhail Pochatkin
>            Priority: Major
>              Labels: s3
>
> There is currently only one way to generate an S3 secret for a user, and that is the S3 namespace in the ozone binary script.
> With this approach, the user must have access to the cluster/node directly or provide it to the cluster administrator. There are two problems here
> 1. The user may not have access to the cluster machine, for example, in the case of a service cluster.
> 2. If the administrator generates an S3 secret using the ozone script, then this secret will be completed and, as a result, all user data. Some environments and companies may have security restrictions on this sensitive information for certain third parties, such as the cluster administrator.
> Here we have no way to automatically and securely generate an S3 secret. 
> As solution I have option to create additional S3 secret HTTP server on S3 Gateway witch will have enable Kerberos HTTP authentication for two endpoint. First one is generate secret, and second one is revoke secret.
> These endpoint will generate S3 secret for user who authorized via Kerberos and provide kerberos token via REST call (for example via curl --negotiate) and return it. In this case no one except user may generate and revoke secret for itself, especially with correct combination with ozone.s3.administrators property settings.
>  
> This S3 security server should have separate configuration properties and may be enabled only in case when node env has Kerberos. By default this server will be disable until configuration will be presented.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org