[
https://issues.apache.org/jira/browse/HDDS-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103300#comment-18103300
]
Fabian Morgan commented on HDDS-16110:
--------------------------------------
Here are a couple of examples where the revocation is useful:
1) A user mistakenly creates an STS token with the wrong permissions. For
example, they only need GetObject and PutObject, but for some reason (maybe
they copied an example online), the token they requested also included
DeleteObject. The token is created and it expires in 2 hours. The user
realizes this after the fact and instead of waiting for the token to expire,
wants to revoke it immediately and create another token with the correct
permissions. Here is where the user revocation is useful.
2) Somehow someone gets access to a Kerberos identity with assume_role
permissions, and starts creating tokens randomly with various permissions. The
S3 (permanent) secret for the Kerberos identity gets revoked and therefore all
the STS tokens in flight that were created are revoked as well. This is an
example where admin revocation is useful.
Also I wouldn't necessarily say "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". That might be one use case. Another use case, as with the
pending smoke tests, is to use *aws configure* with an STS token and issue a
series of S3 api calls while the token lasts. In that case, the token is not
forgotten.
Separately, I had another idea but wanted to discuss internally, so won't post
anything for now.
> 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]
