flyrain commented on code in PR #808:
URL: https://github.com/apache/polaris/pull/808#discussion_r1929068378
##########
spec/rest-catalog-open-api.yaml:
##########
@@ -1595,6 +1595,261 @@ paths:
$ref: '#/components/responses/ServiceUnavailableResponse'
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+
+ /v1/{prefix}/namespaces/{namespace}/policies:
Review Comment:
Here are reasons why policies should not be top-level entities in a Polaris
instance:
1. Policies need a clear ownership structure, either under a catalog or a
namespace, to simplify lifecycle management. For example, you can delete all
policies associated with a catalog or namespace when they are no longer
attached to any entities outside their owner. Typically, there’s a dedicated
team responsible for creating and attaching policies to resource entities, like
tables. This team usually doesn’t own any tables. This design also aligns with
other systems like Snowflake and Dremio, which also put policies under a
catalog or namespace.
2. In Polaris, each catalog maintains its own catalog roles with assigned
privileges. Privileges are not granted directly to principal roles; instead,
they are granted to catalog roles, which are then assigned to principal roles.
With this privilege structure, it is more flexible to put policies under a
catalog/namespace.
--
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]
