I think we should keep this separate from views. A view could be one way to
implement this in engine integration, but I think the best direction is to
pass the metadata directly and with a clear spec instead of trying to
translate to a view in the REST catalog. Translation in the catalog would
(cur
>
> Many of these decisions can be translated together to some sort of view on
> top of a table. Consider user A has permission on table1, column c1 c2,
> sha1 hash mask on email column, row filter age > 21. This can be translated
> into a decision that user A can access a view *SELECT c1, c2, sha1
This may potentially be another thread, but I want to see if we can avoid
excess work/design discussions by utilizing an open policy engine rest api (
https://www.openpolicyagent.org/docs/latest/rest-api/
)that’s already defined and used in Trino now (
https://trino.io/docs/current/security/opa-acc
Thank you Ryan for the detailed suggestions!
So far, it sounds like there are in general 2 types of policy decisions:
1. ones that would fail an execution if not satisfied, e.g. check
constraints, protected column, read/write access to storage, etc.
2. ones that would amend an execution plan, e.g.
I think this is a good idea, but is definitely an area where we need to be
clear about how it would work for people to build with it successfully.
All it takes is one engine to ignore these as the security provided is no
longer applicable.
You’re right that security depends on knowing that the cl
Thanks for the response JB & Micah.
> Is this intended to be information only?
I would expect the engine to honor it to some extent. Consider the case of
writing to a table, LoadTableRequest needs to be able to express this
intent of requesting write access, such that the credentials vended back
Hi Jack,
I think this is an interesting idea but I think there are some practical
concerns (I posted them inline).
- general access patterns, like read-only, read-write, admin full access,
> etc.
Is this intended to be information only? I would hope the tokens and REST
API vending to clients wou
Hi Jack,
It's a good idea and it has to be pluggable.
I think we could have a TableConfigResponse and ViewConfigResponse
that could contain the policy field + key/value pair open list. The
idea is let the REST backend to deal with permission (
We would be able to extend permission this way.
Gen
Hi everyone,
I would like to get some initial thoughts about the possibility to add some
permission control constructs to the Iceberg REST spec. Do we think it is
valuable? If so, how do we imagine its shape and form?
The background of this idea is that, today Iceberg already supports loading
cre
