[
https://issues.apache.org/jira/browse/HADOOP-14507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran updated HADOOP-14507:
------------------------------------
Attachment: HADOOP-14507-001.patch
patch 001. core code, not tests, doesn't go through temp credentials as there's
no URI/bucket there. Doesn't break anything though
essentially, the key fs.s3a.bucket.NAME.secret.key & c are looked for after the
in-URI secrets and before the base fs.s3a.secret.key equivalent. if the bucket
is known. This allows a single JCEKS file to store the secrets for different
buckets, and doesn't require fiddling with load paths for credential
files...something hive blocks.
> extend per-bucket secret key config with explicit getPassword() on
> fs.s3a.$bucket.secret,key
> --------------------------------------------------------------------------------------------
>
> Key: HADOOP-14507
> URL: https://issues.apache.org/jira/browse/HADOOP-14507
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.8.1
> Reporter: Steve Loughran
> Attachments: HADOOP-14507-001.patch
>
>
> Per-bucket jceks support turns out to be complex as you have to manage
> multiple jecks files & configure the client to ask for the right one. This is
> because we're calling {{Configuration.getPassword{"fs,s3a.secret.key")}.
> If before that, we do a check for the explict id, key, session key in the
> properties {{fs.s3a.$bucket.secret}} ( & c), we could have a single JCEKs
> file with all the secrets for different bucket. You would only need to
> explicitly point the base config to the secrets file, and the right
> credentials would be picked up, if set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
