XJDKC commented on code in PR #1191:
URL: https://github.com/apache/polaris/pull/1191#discussion_r2032029644
##########
service/common/src/main/java/org/apache/polaris/service/admin/PolarisAdminService.java:
##########
@@ -664,6 +665,15 @@ private void validateUpdateCatalogDiffOrThrow(
"Cannot modify ExternalId in storage config from %s to %s",
currentStorageConfig, newStorageConfig);
}
+
+ if ((currentAwsConfig.getUserARN() != null
+ &&
!currentAwsConfig.getUserARN().equals(newAwsConfig.getUserARN()))
+ || (newAwsConfig.getUserARN() != null
+ &&
!newAwsConfig.getUserARN().equals(currentAwsConfig.getUserARN()))) {
+ throw new BadRequestException(
+ "Cannot modify userARN in storage config from %s to %s",
Review Comment:
Thanks Dmitri!
> Then it should not be stored in catalog properties at all, IMHO
First, this is an existing behavior, so we can't migrate away from directly.
Right now, `userArn` is provided by polaris itself and stored in catalog
properties when creating the catalog. If we don't store it in catalog
properties, when loading the catalog entities, we need to dynamically inject
the `userArn` info so that it can be included in the `loadCatalog` response.
Users need this info since they need to add this `userArn` in the trust
relationship of their AWS IAM role, in this way polaris can use the
corresponding aws credential of the `userArn` to assume the IAM role.
Creating one `userArn` for each catalog is very expensive (an user arn means
a real AWS user and a AWS credential), instead of relying on different
`userArn`, users should use `externalID` if they only want their IAM role to be
assumed by polaris for a specific catalog.
I will open a thread in `dev` ML, let's discuss on the thread!
--
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]
