[
https://issues.apache.org/jira/browse/HDDS-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102998#comment-18102998
]
István Fajth commented on HDDS-16110:
-------------------------------------
Ok, so just to be sure I understand, this feature is more targeting the user,
but from the user's perspective a short lived token is something that it grabs
assigns to a task fires the task and likely forgets the token. Moreover the
user would not analize audit trails and look for rouge usage of a token
normally.
Administrators on the other hand will not see the actual token unless they see
the occurance of a token in a TRACE log, so based on the audit trail where
rouge usage might pop up in a live threat analisys operations may only have the
option to limit the scope of permissions (again if I understand correctly).
So we have two parties, one does not usually keep a record of tokens it asked
for, the other does not see the token itself unless a very verbose trace log is
analized, and at the end of the day potentially noone ever will revoke a token
based on the token string itself, but we check for it.
Or there may be an even worse practice (from Ozone's point of view) we
encourage to emerge where all users revoke their tokens after they finish using
it, and these lookups might get costly in the request processing.
For me this implies that we do not really need this kind of revocation, but I
can accept if you think it is still useful.
> 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]
