You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "UENISHI Kota (Jira)" <ji...@apache.org> on 2021/05/27 09:02:00 UTC
[jira] [Commented] (HDDS-4696) Disable or revoke s3 secret by a
user and an admin
[ 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: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org