[
https://issues.apache.org/jira/browse/HADOOP-14556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630349#comment-16630349
]
Steve Loughran commented on HADOOP-14556:
-----------------------------------------
bq. I did this so long ago, w/o understanding as much about s3 as you, that I
need to refresh my memory on whether it was intentional or not.
it certainly makes sense if you allow >1 login for a specific bucket, e.g
{code}
fs1 = Filesystem.get("s3a://user1:keyt@bucket1")
fs2 = Filesystem.get("s3a://user2:key2@bucket1")
{code}
then submit some job which reads from both filesystem instances. the FS1 DT
would have the session info of user1; that of the FS2 DT would be that of the
session info of user2. Having the user in the URI would be needed to ensure
that the right DT was retrieved for the different filesystems, so the
restricted permissions picked up
One other thing your patch does well is ask the existing auth chain for session
tokens and uses them too. I want to make sure I can do that too, as a use case
I'm thinking of is "yubikey authenticated user submitting credentials with a
job". I don't think such a user can call assumeRole() (as they get session
credentials with the 2FA login), but their original session tokens can be
propagated
bq. Some of the design consideration your highlight, such always getting a STS
token, were purposeful shortcuts (hence not submitted to community) since
internally it is a solid requirement.
I understand. But I also know that you understand a lot more about how DTs work
than me, so if there is something I don't understand, my first assumption is
generally "I need to know more"
> S3A to support Delegation Tokens
> --------------------------------
>
> Key: HADOOP-14556
> URL: https://issues.apache.org/jira/browse/HADOOP-14556
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.2.0
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Major
> Attachments: HADOOP-14556-001.patch, HADOOP-14556-002.patch,
> HADOOP-14556-003.patch, HADOOP-14556-004.patch, HADOOP-14556-005.patch,
> HADOOP-14556-007.patch, HADOOP-14556.oath-002.patch, HADOOP-14556.oath.patch
>
>
> S3A to support delegation tokens where
> * an authenticated client can request a token via
> {{FileSystem.getDelegationToken()}}
> * Amazon's token service is used to request short-lived session secret & id;
> these will be saved in the token and marshalled with jobs
> * A new authentication provider will look for a token for the current user
> and authenticate the user if found
> This will not support renewals; the lifespan of a token will be limited to
> the initial duration. Also, as you can't request an STS token from a
> temporary session, IAM instances won't be able to issue tokens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
