István Fajth created HDDS-16110:
-----------------------------------
Summary: s3RevokedStsTokenTable key is the full token str
Key: HDDS-16110
URL: https://issues.apache.org/jira/browse/HDDS-16110
Project: Apache Ozone
Issue Type: Sub-task
Components: S3
Reporter: István Fajth
Assignee: Fabian Morgan
During gathering a deeper understanding on what can be a common ground between
the Custos design that is being discussed over
[GitHub|https://github.com/apache/ozone/pull/10742] I found a potential
operational problem with STS token revocation. [~fmorgan] can you please look
into this?
Based on the revocation check code path, it seems for me that the full token
str (which is essentially the client's secret) is being used as the key in the
revocation table.
In
[S3SecurityUtil|https://github.com/apache/ozone/blob/HDDS-13323-sts/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/security/S3SecurityUtil.java#L77]
the check goes by the full token string extraced from the request.
This means that the admins would need to revoke a token based on the actual
token content which if my understanding is correct should be kept secret
between the client and the server morover which we do not log anywhere for the
same reason.
So this means that essentially the only way to revoke a token is by knowing the
token, and that should be known only by the client who asked for the token.
May we use some id that we already have generated for the token that is present
in the audit logs where a rouge access with a token may be identified?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
