[
https://issues.apache.org/jira/browse/HDDS-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102872#comment-18102872
]
Fabian Morgan commented on HDDS-16110:
--------------------------------------
hi [~pifta], thanks for asking about this. Actually, the sessionToken is `not`
secret - indeed it is sent in the header for S3 requests so any web server that
logs headers would log the sessionToken. Further, no one can invoke any S3
calls with just the sessionToken; they must know the `secretAccessKey` as well,
so the `secretAccessKey` is what needs to be kept confidential. So the
`sessionToken` can be freely logged, but not the `secretAccessKey` - see
https://github.com/fmorg-git/ozone/blob/26380fdf76abf997339c96f035dd5e4d8570c88e/hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/helpers/AssumeRoleResponseInfo.java#L82-L87
for example.
cc: [~sammichen]
> 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
> Priority: Major
>
> 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]
