[HADOOP-15583] Stabilize S3A Assumed Role support

• Type: Sub-task
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 3.1.0
• Fix Version/s: 3.2.0
• Component/s: fs/s3
• Target Version/s: 3.2.0
• Assignee: Steve Loughran
• Reporter: Steve Loughran
• Created: 05/Jul/18 20:54
• Updated: 04/Feb/19 11:16
• Resolved: 09/Aug/18 05:58

Description

started off just on sharing credentials across S3A and S3Guard, but in the process it has grown to becoming one of stabilising the assumed role support so it can be used for more than just testing.

Was: "S3Guard to get AWS Credential chain from S3AFS; credentials closed() on shutdown"

Issue: lack of auth chain sharing causes ddb and s3 to get out of sync

S3Guard builds its DDB auth chain itself, which stops it having to worry about being created standalone vs part of an S3AFS, but it means its authenticators are in a separate chain.

When you are using short-lived assumed roles or other session credentials updated in the S3A FS authentication chain, you need that same set of credentials picked up by DDB. Otherwise, at best you are doubling load, at worse: the DDB connector may not get refreshed credentials.

Proposed: DynamoDBClientFactory.createDynamoDBClient() to take an optional ref to aws credentials. If set: don't create a new set.

There's one little complication here: our AWSCredentialProviderList list is autocloseable; it's close() will go through all children and close them. Apparently the AWS S3 client (And hopefully the DDB client) will close this when they are closed themselves. If DDB has the same set of credentials as the FS, then there could be trouble if they are closed in one place when the other still wants to use them.

Solution; have a use count the uses of the credentials list, starting at one: every close() call decrements, and when this hits zero the cleanup is kicked off

Issue: AssumedRoleCredentialProvider connector to STS not picking up the s3a connection settings, including proxy.

issue: we're not using getPassword() to get user/password for proxy binding for STS. Fix: use that and pass down the bucket ref for per-bucket secrets in a JCEKS file.

Issue; hard to debug what's going wrong

Issue: docs about KMS permissions for SSE-KMS are wrong, and the ITestAssumedRole* tests don't request KMS permissions, so fail in a bucket when the base s3 FS is using SSE-KMS. KMS permissions need to be included in generated profiles

Issue Links

• contains: HADOOP-15572 Test S3Guard ops with assumed roles & verify required permissions
• contains: HADOOP-15627 S3A ITestS3GuardWriteBack failing if bucket explicitly set to s3guard+DDB
• contains: HADOOP-15232 AWSCredentialProviderList to throw custom NoCredentialsException; retry logic to handle
• contains: HADOOP-15569 Expand S3A Assumed Role docs
• contains: HADOOP-15592 AssumedRoleCredentialProvider to propagate connection settings of S3A FS
• incorporates: HADOOP-15573 s3guard set-capacity to not retry on an access denied exception
• is depended upon by: HADOOP-14556 S3A to support Delegation Tokens
• is related to: HADOOP-15572 Test S3Guard ops with assumed roles & verify required permissions
• relates to: HADOOP-15426 Make S3guard client resilient to DDB throttle events and network failures
• relates to: HADOOP-15642 Update aws-sdk version to 1.11.375