[
https://issues.apache.org/jira/browse/HDDS-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352345#comment-17352345
]
UENISHI Kota commented on HDDS-4696:
------------------------------------
Implemented at HDDS-5206. Thanks!
> Disable or revoke s3 secret by a user and an admin
> --------------------------------------------------
>
> Key: HDDS-4696
> URL: https://issues.apache.org/jira/browse/HDDS-4696
> Project: Apache Ozone
> Issue Type: New Feature
> Affects Versions: 1.0.0
> Environment: Secure setup of Ozone
> Reporter: UENISHI Kota
> Priority: Critical
> Attachments: revoke.patch
>
>
> As of 1.0.0 or today's master, there is no way to disable or to revoke
> existing s3 secret. S3 secrets remain available even after UPN tokens
> expired, revoked or removed. This can be a security risk especially in case
> when S3 secrets leaked to malicious 3rd party. In that case, there are no way
> to prevent them accessing to the system, as the created-and-leaked S3 secret
> remains almost forever inside OM, if I understand correctly.
> To address this issue, there may be two ways. (1) One is to add a feature to
> revoke the S3 secret, say, like "ozone s3 revokesecret" to revoke the S3
> secret, which deletes the secret from the whole cluster. Users re-create the
> secret via "ozone s3 getsecret". I worry about consistency on concurrent call
> of get and revoke, which may freak out replication in OM. (2) Another way is
> to modify `getsecret` subcommand to recreate the secret behind, every time
> when it was invoked. In this way, pro is that the change is rather small than
> (1), but the idempotent nature of `getsecret` will be changed. The secret
> changes every time "get"-secret invoked, which looks strange.
> I created a PoC patch that implements (1) in a naive and hacky way (it's a
> bit old based on 547143231aa7 ) and it worked somehow as intended, but want
> to discuss how it should be addressed.
> I also want to find out how to workaround this issue - like changing owner of
> buckets in /s3v, or denying somehow?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
