This is a highly requested feature. Thank you for working on this, Prashant!
I look forward to reviewing the design doc. Yufei On Thu, Nov 5, 2026 at 12:16 AM Jean-Baptiste Onofré <[email protected]> wrote: > > 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 > >
