The `userARN` is not stored in Polaris (is ignored)

[tomekl007]

Describe the bug

Looks like userARN is only used during reading, but not when it is written.
It seems like dead code in polaris-oss.

We should be able to store the userARN (similarly to roleArn and externalId) Now it is not possible.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response

[adutra]

Hi @tomekl007 unfortunately this is by design and will likely not change.

See #1506 for context.

In short, userArn is an output-only property because it's meant to be provided by Polaris itself, and is global to the Polaris instance.

\cc @XJDKC @dimas-b

[tomekl007]

I understand, so maybe in that case, the setUserArn method should be removed from:
org.apache.polaris.core.admin.model.AwsStorageConfigInfo
since it won't be stored?

[adutra]

I understand, so maybe in that case, the setUserArn method should be removed from: org.apache.polaris.core.admin.model.AwsStorageConfigInfo since it won't be stored?

I think the setter is still required, so that Polaris can set the userArn on it.

@XJDKC how does Polaris retrieve the userArn exactly? Environment variables? I don't see anything in the code base 🤔

[dimas-b]

Apache Polaris itself does not use userArn, AFAIK. This is an informative parameter for Polaris users to consider when configuring IAM rules for Polaris to access S3 storage.

The userArn parameter is currently applicable when Polaris is managed by one organization (which configures userArn at deployment time) but accesses S3 in another organization.

Related discussed happened under #1506.

[adutra]

which configures userArn at deployment time

But how? I don't see this value being sourced from anything (configuration files or environment variables).

[dimas-b]

The exact mechanism for configuring userArn is not well-defined, AFAIK

[XJDKC]

how does Polaris retrieve the userArn exactly?

Unfortunately, the behavior is not well defined in OSS Polaris. Open Catalog has its own implementation. Ideally, this info should be provided by polaris itself in another way (shouldn't be part of the create catalog request). So setUserArn is still required so that Polaris can providing this info by calling this method to generate the load catalog response.

I have a proposal for configuring the userArn via the Quarkus config file, details are in this PR: #1805

This PR includes:

• A default implementation that allows configuring the userArn via the Quarkus config file. In this case, adding a new service identity would require a server restart.
• A runtime extension point (ServiceIdentityRegistry) that enables dynamic configuration of service identities without restarting the server.