[
https://issues.apache.org/jira/browse/HDDS-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
UENISHI Kota updated HDDS-4696:
-------------------------------
Description:
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?
was:
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.
> Disable or revoke s3 secret by a user and an admin
> --------------------------------------------------
>
> Key: HDDS-4696
> URL: https://issues.apache.org/jira/browse/HDDS-4696
> Project: Hadoop Distributed Data Store
> Issue Type: New Feature
> Affects Versions: 1.0.0
> Environment: Secure setup of Ozone
> Reporter: UENISHI Kota
> Priority: Major
> 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]
