Hi Prashant Thanks for the update, and awesome to see progress ;)
That's really great to have ReadRestrictions in the Iceberg REST Spec, it's a big step. It gives us a standard way to return the policy result to engines in the loadTable response, so we don't need a Polaris specific endpoint. I have some comments about the new draft: - I'm +1 with Laurent about the trust. I believe the trust question is the same as for referenced-by discussion, so probably better to define once for both. The engine enforces the restrictions. A client that doesn't support read restrictions will just ignore the field, and with vended credentials it can read the data files directly anyway. I think it would be great to have a proposal about that, clearly describing what Polaris does when a restriction applies and the caller is not trusted. My preference would be to fail asap (no load at all) rather than returning restrictions. - Polaris has pluggable authorizers (built in, OPA, Ranger), and Ranger already has row filtering and masking policies. I think read restrictions should come from an extension point, with the Polaris policy store as the build in impl. That way OPA or Ranger users can also return read restrictions. It's a similar approach as for referenced-by: Polaris does the plumbing, the authorizer makes the decision. - With the existing policy framework, several policies can apply to the same table (attached at catalog, namespace, table level). The spec says a server must not return more than one projection for the same field-id. So, we should define how we combine row filters and how we resolve conflicting projections on the same column. Regards JB On Wed, Nov 4, 2026 at 10:50 PM Prashant Singh <[email protected]> wrote: > Hi everyone, > > I'm picking back up the work on Row-Level Security (RLS) and Column-Level > Security (CLS) policies [1]. > > What's coming next, I'll share a new draft of the Polaris Policies proposal > soon. It will include: > • Updated policy definitions > • Policy attachment semantics built on Apache Iceberg ReadRestrictions > > Progress so far > Working with several project communities, we've added ReadRestrictions to > the Apache Iceberg spec [2]: > • Engine portability: policy results are expressed as Iceberg expressions > and actions, so any engine can enforce them consistently, one of the main > discussion points in the original PR, and it's now handled. > > Feedback is welcome as the new draft takes shape. Thanks to everyone who > has helped get us here. > > Best, > Prashant > > [1] https://github.com/apache/polaris/pull/2048 > [2] https://github.com/apache/iceberg/pull/13879 >
