dimas-b commented on code in PR #3170:
URL: https://github.com/apache/polaris/pull/3170#discussion_r2572307901
##########
polaris-core/src/main/java/org/apache/polaris/core/storage/aws/AwsCredentialsStorageIntegration.java:
##########
@@ -90,35 +96,46 @@ public StorageAccessConfig getSubscopedCreds(
StorageAccessConfig.Builder accessConfig = StorageAccessConfig.builder();
if (shouldUseSts(storageConfig)) {
- AssumeRoleRequest.Builder request =
- AssumeRoleRequest.builder()
- .externalId(storageConfig.getExternalId())
- .roleArn(storageConfig.getRoleARN())
- .roleSessionName("PolarisAwsCredentialsStorageIntegration")
- .policy(
- policyString(
- storageConfig,
- allowListOperation,
- allowedReadLocations,
- allowedWriteLocations,
- region,
- accountId)
- .toJson())
- .durationSeconds(storageCredentialDurationSeconds);
- credentialsProvider.ifPresent(
- cp -> request.overrideConfiguration(b -> b.credentialsProvider(cp)));
@SuppressWarnings("resource")
// Note: stsClientProvider returns "thin" clients that do not need
closing
StsClient stsClient =
stsClientProvider.stsClient(StsDestination.of(storageConfig.getStsEndpointUri(),
region));
-
- AssumeRoleResponse response = stsClient.assumeRole(request.build());
- accessConfig.put(StorageAccessProperty.AWS_KEY_ID,
response.credentials().accessKeyId());
- accessConfig.put(
- StorageAccessProperty.AWS_SECRET_KEY,
response.credentials().secretAccessKey());
- accessConfig.put(StorageAccessProperty.AWS_TOKEN,
response.credentials().sessionToken());
- Optional.ofNullable(response.credentials().expiration())
+ Credentials credentials;
+ if (storageConfig.getUserTokenSTS()) {
+ AssumeRoleWithWebIdentityRequest.Builder request =
+ AssumeRoleWithWebIdentityRequest.builder()
+ .webIdentityToken(
+
securityIdentity.getCredential(PolarisCredential.class).getToken())
+ .roleArn(storageConfig.getRoleARN())
+ .roleSessionName("PolarisAwsCredentialsStorageIntegration")
+ .durationSeconds(storageCredentialDurationSeconds);
Review Comment:
Access down-scoping (policy-based restrictions) makes more sense in the case
when Polaris has its own "service" credential because we do not want to
delegate more rights to the user than what is necessary for the API request.
In this case the STS session is based in the unmodified API user identity.
The user can gain the same access by talking to STS directly.
The only reason for restricting access might be to enforce catalog-level
location settings. However, that would be mostly about preventing accidental
mistakes on the client side rather than a true security control.
That said, for the sake of narrowing Polaris behaviour variations it might
still be worth applying the same policy as in the "service" account case...
just for ease of reasoning about how the system works.
Taking this one step further, it might be worth controlling the policy
application with yet another config property, if there are use case when the
extra policy in not desirable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
