-
Notifications
You must be signed in to change notification settings - Fork 332
Make ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS configurable per catalog #2688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -511,13 +511,18 @@ private void authorizeGrantOnTableLikeOperationOrThrow( | |||||||||
| } | ||||||||||
| } | ||||||||||
|
|
||||||||||
| CatalogEntity catalogEntity = | ||||||||||
| CatalogEntity.of( | ||||||||||
| findCatalogByName(catalogName) | ||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it not part of
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The name of this helper is somewhat misleading: polaris/runtime/service/src/main/java/org/apache/polaris/service/admin/PolarisAdminService.java Lines 193 to 196 in 925c00b
Underlying it just extract the entity from the resolutionManifest, the name is ignored : )
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sweet :) Mind removing the unused parameter for clarity?.. maybe in another PR, if you prefer :)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will do it in a follow-up as it will affect other part of the code. |
||||||||||
| .orElseThrow(() -> new NotFoundException("Catalog %s not found", catalogName))); | ||||||||||
| PolarisResolvedPathWrapper tableLikeWrapper = | ||||||||||
| resolutionManifest.getResolvedPath( | ||||||||||
| identifier, PolarisEntityType.TABLE_LIKE, PolarisEntitySubType.ANY_SUBTYPE, true); | ||||||||||
| boolean rbacForFederatedCatalogsEnabled = | ||||||||||
| getCurrentPolarisContext() | ||||||||||
| .getRealmConfig() | ||||||||||
| .getConfig(FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS); | ||||||||||
| .getConfig( | ||||||||||
| FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS, catalogEntity); | ||||||||||
| if (!(resolutionManifest.getIsPassthroughFacade() && rbacForFederatedCatalogsEnabled) | ||||||||||
| && !subTypes.contains(tableLikeWrapper.getRawLeafEntity().getSubType())) { | ||||||||||
| CatalogHandler.throwNotFoundExceptionForTableLikeEntity(identifier, subTypes); | ||||||||||
|
|
@@ -1710,7 +1715,9 @@ public PrivilegeResult grantPrivilegeOnNamespaceToRole( | |||||||||
| boolean rbacForFederatedCatalogsEnabled = | ||||||||||
| getCurrentPolarisContext() | ||||||||||
| .getRealmConfig() | ||||||||||
| .getConfig(FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS); | ||||||||||
| .getConfig( | ||||||||||
| FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS, | ||||||||||
| catalogEntity); | ||||||||||
| if (resolutionManifest.getIsPassthroughFacade() && rbacForFederatedCatalogsEnabled) { | ||||||||||
| resolvedPathWrapper = | ||||||||||
| createSyntheticNamespaceEntities(catalogEntity, namespace, resolvedPathWrapper); | ||||||||||
|
|
@@ -2136,7 +2143,9 @@ private PrivilegeResult grantPrivilegeOnTableLikeToRole( | |||||||||
| boolean rbacForFederatedCatalogsEnabled = | ||||||||||
| getCurrentPolarisContext() | ||||||||||
| .getRealmConfig() | ||||||||||
| .getConfig(FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS); | ||||||||||
| .getConfig( | ||||||||||
| FeatureConfiguration.ENABLE_SUB_CATALOG_RBAC_FOR_FEDERATED_CATALOGS, | ||||||||||
| catalogEntity); | ||||||||||
| if (resolutionManifest.getIsPassthroughFacade() && rbacForFederatedCatalogsEnabled) { | ||||||||||
| resolvedPathWrapper = | ||||||||||
| createSyntheticTableLikeEntities( | ||||||||||
|
|
||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To continue the discussion #2223 (comment),
I am +1 on making this configurable at catalog level too. But I am a little bit worried about allowing user/catalog admin to to turned it off after it turned on.
Currently we have 2 model,
Without JIT creation, user will find grant to namespace/tables fail with 404
With JIT creation, user should be able to grant to namespace/tables as if they exists.
If we allow users to turn JIT creation off after turned it on for some time, the federated catalog will be in a weird status where some of namespaces/tables with JIT entities backfilled, could still accept new grants/revokes, other namespaces/tables grants will fail with 404.
To address this inconsistency, I see 2 option:
truetofalseduring catalog update.IMHO, 2 is safer since even if we block further grants, the existing grant records will still take effect during loadTable/createTable/..etc.
But would love to hear more thoughts on this! We could also decide this in a follow-up PR
cc: @dennishuo @dimas-b
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, @HonahX !
In general, this feels like we need to enhance our feature flags support to allow more control on the Polaris "owner" side.
I do believe setting this particular flag per catalog is useful for self-hosted environments (where owner == admin user).
For Polaris-as-a-Service deployments, we probably need to restrict certain settings to be managed only by the owner, who may not be the same subject as the catalog user or administrator.
In short term, WDYT about adding another feature flag (defaulting to "allowed") to control whether
polaris.config.enable-sub-catalog-rbac-for-federated-catalogsmay be added to Catalog properties (existing similar use case: #2442)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @dimas-b , nice suggestion! I think adding a mechanism for the "owner" to optionally restrict changes to potentially high-impact parameters on a per-catalog basis would help mitigate this situation.
Given the refactoring and follow-up changes we’ve already identified, I’ll go ahead and merge this first and open other ones.