[
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: [email protected]
For additional commands, e-mail: [email protected]
