laskoviymishka commented on code in PR #13879:
URL: https://github.com/apache/iceberg/pull/13879#discussion_r3685080218
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1051,6 +1051,16 @@ paths:
table. The configuration key "token" is used to pass an access token
to be used as a bearer token
for table requests. Otherwise, a token may be passed using a RFC 8693
token type as a configuration
key. For example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+
+
+ The response may include a read-restrictions field. A reader that
supports read
Review Comment:
> the reality is vended creds are output of GRANTs one user has on the
catalog ... so i kind of disagree here its not identity based
Yeah, fair. You're right, both are tied to the caller's identity:
credentials come from that caller's grants, and restrictions come from the
policy applied to them.
> Read restriction are just more fine grained than the coarse grained grants.
Agreed, they're on the same granularity continuum. The distinction I was
trying to make is where enforcement happens.
Vended credentials are enforced at the storage layer. The object store only
returns files allowed by the credential, regardless of what the client does.
Even a buggy client with a path-scoped credential cannot read outside that
scope.
Row filters and column masks cannot be enforced there. The storage layer
deals with files and row groups, not logical rows, so the engine receives the
raw data and has to apply the restriction itself.
So the distinction is less "coarse vs. fine-grained grants" and more
"storage-enforced vs. client-enforced." Credentials have a storage-layer
backstop; read restrictions do not.
That's the point I was trying to make about the per-principal assumption
carrying more weight for read restrictions.
--
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]
