laskoviymishka commented on PR #15750: URL: https://github.com/apache/iceberg/pull/15750#issuecomment-5102044745
Thanks @singhpk234 for review! Let me unpack the POC, i think that section is oversold and it's dragging the wrong framing onto the thread. _Disclaimer_: this isn't a governance proposal and labels don't mandate any enforcement model. the POC is one thing a consumer can do with labels, not the way to govern iceberg. The pair is an IRC catalog → ClickHouse. The explicit view you found is there because ClickHouse enforces access control natively: `roles`, `row policies`, `column grants` -- all evaluated inside the server. It has no Ranger plugin and no per-query external-authorizer hook the way Trino/Hive do, so it can't consume a catalog-side policy decision at query time. That's why the POC looks like "classification in catalog, policy in engine", it's not a pattern i'm pushing, it's just the shape ClickHouse already has. Engine-enforcement isn't specific to ClickHouse: Postgres (RLS + column grants) and MySQL (grants, view-based row filtering) enforce the same way and have no per-query external-authorizer path either. Any of them consuming a catalog would act on classification with its own primitives rather than a catalog-side decision. Which is also the honest answer to "why not ReadRestrictions directly". I don't see these as competing: `ReadRestrictions` returns a decision, catalog is the **authority**. `Labels` return classification and leave the decision to the consumer. `ReadRestrictions` also can't represent every policy scenario, so it's not a full substitute either way. Conceptually `labels` are aligned with a policy-coordination system like Ranger/Immuta: the difference is the context arrives from a REST catalog instead of an internal one, but the net result is the same. A catalog can do **both**. Where the policy store sits behind the catalog and identity resolves cleanly catalog-side (Trino+Ranger, Spark+catalog), `ReadRestrictions` is the right tool and `labels` aren't trying to replace it. ClickHouse just isn't that case - its SQL identities don't map 1:1 to catalog principals so the catalog can't resolve whose decision to return, and it queries well beyond iceberg so it wants one policy layer across all its sources, not a per-catalog decision for the iceberg slice. so for that engine, catalog-provides-classification + engine-enforces is the thing that actually fits, not a claim that it's better in general. _Stepping back_: governance is **one** consumer of labels, next to _discovery_, _cost attribution_, _semantic/AI context_. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
