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

UENISHI Kota resolved HDDS-4696.
--------------------------------
    Fix Version/s: 1.2.0
       Resolution: Duplicate

> 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
>             Fix For: 1.2.0
>
>         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]

Reply via email to