jerryshao commented on code in PR #13546: URL: https://github.com/apache/gravitino/pull/13546#discussion_r4143462116
########## design-docs/tag-based-read-restrictions-for-iceberg-rest.md: ########## @@ -0,0 +1,562 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Design: Tag-Based Read Restrictions for Iceberg REST + +## Background + +Gravitino can associate governance policies with tags and resolve those policies for metadata +objects. Existing authorization decides whether a subject may read a table, but it cannot restrict +which rows or column values are visible after access is granted. + +The Iceberg REST specification defines `read-restrictions` in a load-table response. A conforming +reader applies a required row filter and required column projections before returning data. This +provides a standard enforcement boundary for portable restrictions. + +This design adds tag-based row-filter and column-mask policies and resolves them into Iceberg REST +`read-restrictions`. It is disabled by default and requires an explicit client capability +declaration while reader support is maturing. + +## Goals + +1. Define typed row-filter and column-mask policy content. +2. Select policies through the policy-on-tag model and effective tags. +3. Support small, deterministic expression syntax for row predicates and mask selection. +4. Bind authored expressions to the authenticated subject and an Iceberg table schema. +5. Return only closed, typed Iceberg expressions and standard Iceberg mask actions. +6. Fail closed when an applicable restriction cannot be resolved or enforced. +7. Provide an end-to-end path that can later move to official Iceberg runtime types without + changing policy content. +8. Reserve a fail-closed extension model for UDF references. + +## Non-Goals + +1. Replacing table-level authorization or granting access through a read-restriction policy. +2. Executing arbitrary expressions or UDFs through the first Iceberg REST implementation. +3. Supporting nested-field masks, roles, identity attributes, nested groups, or general attribute + expressions in the first version. +4. Defining a new direct policy-to-metadata-object association model. +5. Guaranteeing that a reader without Iceberg read-restriction support can safely read governed + tables. + +## Architecture + +The resolution path is: + +```text +Policy and tag administration + -> effective tags for a table and its columns + -> effective row-filter and column-mask policies + -> subject and schema binding + -> canonical Iceberg read restrictions + -> loadTable response + -> trusted Iceberg reader enforcement +``` + +Authorization runs before restriction resolution. A restriction only reduces data visible through +an already-authorized read. It never changes an authorization deny into an allow. + +The first implementation runs only where the Iceberg REST service has the trusted end user in its +request context and can resolve Gravitino policies, tags, users, and groups directly. + +## Policy Model + +This design introduces two built-in policy types: + +| Policy type | Evaluation target | Effect | +| --- | --- | --- | +| `system_row_filter` | Table | Retains only rows matching one resolved predicate. | +| `system_column_mask` | Top-level column | Replaces visible values using one Iceberg mask action. | Review Comment: Can we bind this to the schema and specify the affected table/column? Or we can only bind to the table/column? -- 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]
