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 client is going to enforce the requirements sent by the catalog. That just means that the catalog either needs to deny access (401/403 response) or have some pre-established trust in the identity that is loading a table (or view). The current authentication mechanisms that we’ve documented have ways to do this. For example, if you’re using a token scheme you can put additional claims in the auth token when the client is trusted to enforce fine-grained access. To establish trust, you can either manually create a token for a compute service with the trust selected or we could add another OAuth2 scope to request it when connecting compute engines to catalogs. Either way, we already have mechanisms to establish trust relationships between engines and catalogs so this would just be an additional capability. I worry a little bit about putting security features into the REST API that require the execution engine and catalog to agree on semantics and execution. I agree in the general case, but I think there are narrow cases where we are already handling this problem and solving those is incredibly useful. I think a critical design constraint is that this extension should be used to pass requirements — the result of policy decisions — and NOT be used to pass policy itself. (And, I would change the proposed policy field in REST responses to requirements or similar to make this clear.) Policy is complicated and it is modelled and enforced differently across products. Databases all have their own rules. For instance, in some schemes database SELECT cascades to table SELECT, while others check only the table resource for SELECT permission. I think we clearly don’t want to try to normalize or force a standard on this space. Instead, we want catalogs and access control systems to have the model that they choose. The REST protocol should communicate the decisions made by those schemes. That significantly narrows the scope of this feature. Starting with fields that can or can’t be read and filters that must be applied is a great start that covers a large number of use cases. And we already have clear semantics for Iceberg filters and for column projection. We would still need to specify additional guidance, but semantics and execution are possible to agree on if we start small. Here’s some additional guidance I would add: - Projection: the client is not allowed to read certain fields, specified by field ID, even if those fields are not part of the output. This avoids leaks using queries like SELECT count(1) FROM bank_accounts WHERE email = ? where email is a protected column. - Filtering: rows that do not match the filter must be removed immediately after loading the data, before rows or groups of rows are passed to any other operator. Jack also suggested passing permissions back, which I don’t think I would include. There was some discussion about using this to identify catalogs that are secondary references; I think that’s okay but I would make it a much more narrow option, like supports-commit: false rather than specifying a set of privileges. As for the idea about sending write constraints, this is an interesting idea. I think we could make it work the same way that row and column filters would work. If the client is trusted to support it, then it is responsible for checking those constraints and not attempting to commit changes. There’s not need to complicated the commit protocol if the chain of trust includes the ability to enforce constraints. Plus, constraints may need to be known during job execution, not just at commit time, so it is better to send them when loading a table. Ryan On Tue, Feb 20, 2024 at 1:44 PM Jack Ye <yezhao...@gmail.com> wrote: > 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 in > LoadTableResponse can have write access. > > > I worry a little bit about putting security features into the REST API > that require the execution engine and catalog to agree on semantics and > execution. All it takes is one engine to ignore these as the security > provided is no longer applicable. > > I think replicating this would be challenging, since it requires > distinguishing between direct user access to the catalog and a query engine > working on a user's behalf. > > Yes, I have the same concerns, that's why I am trying to gather some > community feedback here. I think it is possible to distinguish a normal > user vs a specific engine. At least in the AWS world, we figured out a way. > If an engine is accessing the Glue API, it must go through an onboarding > process > <https://docs.aws.amazon.com/lake-formation/latest/dg/Integrating-with-LakeFormation.html>. > After that process, there is a shared responsibility model: any requests > from the authorized engine will contain sensitive information like > credentials, filters, etc. The engine needs to make sure that these > sensitive information are not exposed when fulfilling query executions. > Normal users calling the catalog with their personal credentials do not see > anything sensitive. This limits the end users to always use an authorized > engine for actual data read and write, which is intended. > > From a feature perspective, there is an opportunity I see to create a spec > about these common security constructs that different engine integrations > can try to follow. Specific authorization mechanisms like the one I > described above can be left to the individual catalog services to figure > out. > > Just looking at the initial feedback, it sounds like at least it is an > interesting idea that is worth exploring. I can provide a more detailed doc > for us to review. > > Best, > Jack Ye > > On Fri, Feb 16, 2024 at 10:29 AM Micah Kornfield <emkornfi...@gmail.com> > wrote: > >> 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 would enforce these settings, so it seems like >> this would mostly be for debug purposes (e.g. if only read access is >> available, only tokens with "read" privileges are vended, or without full >> access admin rights update to the catalog would not be allowed). >> >> - columns that the specific caller has access to for read or write >>> - filters (maybe expressed in Iceberg expression) that should be applied >>> by the engine on behalf of the caller during a table scan >> >> I have a few concerns here: >> 1. I worry a little bit about putting security features into the REST >> API that require the execution engine and catalog to agree on semantics and >> execution. All it takes is one engine to ignore these as the security >> provided is no longer applicable. For more tightly controlled environments >> this is viable but it feels like some very large consequences if users make >> the wrong choice on engine or even if there is an engine using a stale REST >> API client (i.e. we would need to be very careful with >> compatibility guarantees). >> 2. The row-level security feature linked is designed so that end-users >> are not aware of which, if any, filters were applied during the query. I >> think replicating this would be challenging, since it requires >> distinguishing between direct user access to the catalog and a query engine >> working on a user's behalf. >> 3. In terms of dialect, I imagine it would probably make sense to be >> agnostic here and follow a similar model that views are taking by allowing >> multiple dialects (or at least wait to see how the view works out in >> practice). >> >> >> For points 1 and 2 a different approach would be to introduce a new >> standard based on something like Apache Arrow's Flight or Flight SQL >> protocol that acts as a layer of abstraction between physical storage and >> security controls. >> >> - constraints (again, maybe expressed in Iceberg expression) that should >>> trigger the table scan or table commit to be rejected >> >> >> It feels like this should probably be part of the table spec, as in >> general, it affects the commit protocol (IIUC it is already covered >> partially with identifier-field IDs). >> >> Thanks, >> Micah >> >> >> >> On Tue, Feb 13, 2024 at 10:42 AM Jack Ye <yezhao...@gmail.com> wrote: >> >>> 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 >>> credentials to a table through the config field >>> <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L2714-L2719> >>> in LoadTableResponse, as a basic way to control data access. We heard that >>> users really like this feature and want more regarding data access control >>> and permission configuration in Iceberg. >>> >>> For example, we could consider add a *policy* field in the REST >>> LoadTableResponse, where a policy has sub-fields that describe: >>> - general access patterns, like read-only, read-write, admin full >>> access, etc. >>> - columns that the specific caller has access to for read or write >>> - filters (maybe expressed in Iceberg expression) that should be applied >>> by the engine on behalf of the caller during a table scan >>> - constraints (again, maybe expressed in Iceberg expression) that should >>> trigger the table scan or table commit to be rejected >>> >>> This could be the solution to some topics we discussed in the past. For >>> example, we can use this as a solution to the EXTERNAL database >>> semantics support discussion >>> <https://lists.apache.org/thread/ohqfvhf4wofzkhrvff1lxl58blh432o6> by >>> saying an external table has read-only access. We can also let the REST >>> service decide access to columns, which solves some governance issues >>> raised during the column tagging discussion >>> <https://lists.apache.org/thread/yflg8w1h87qgwc4s3qtog4l8nx8nk8m0>. >>> >>> Outside existing discussions, this can also work pretty well with >>> popular engine vendor features like row-level security >>> <https://cloud.google.com/bigquery/docs/row-level-security-intro>, check >>> constraint <https://docs.databricks.com/en/tables/constraints.html>, >>> etc. >>> >>> In general, permission control and data governance is an important >>> aspect for enterprise data warehousing. I think having these constructs in >>> the REST spec and related engine integration could increase enterprise >>> adoption and help our vision of standardizing access through the REST >>> interface. >>> >>> Would appreciate any thoughts in this domain! And if we have some >>> general interest in this direction, I can put up a more detailed design doc. >>> >>> Best, >>> Jack Ye >>> >> -- Ryan Blue Tabular
