roryqi commented on code in PR #14595:
URL: https://github.com/apache/gravitino/pull/14595#discussion_r4463234091
##########
docs/iceberg-rest-service.md:
##########
@@ -260,6 +260,44 @@ IRC1 must also configure S3 configurations if the client
side requests credentia
If IRC2 does not enforce authorization, keeping
`gravitino.iceberg-rest.disable-rest-authz=true` can leave operations
unprotected. Set it to `false` to enforce authorization in IRC1.
:::
+##### Service account connection
+
+By default IRC1 forwards each user's access token to IRC2, so IRC2 must trust
the same identity provider and authorize every user itself. To federate a
catalog that cannot do that, such as a managed catalog that accepts only its
own API token, connect IRC1 to IRC2 as a service account. IRC1 then presents
one configured credential on every request to IRC2 and authorizes each user
against Gravitino's own grants before anything is proxied. A catalog connected
as a service account always enforces authorization in IRC1, whatever
`disable-rest-authz` is set to, and IRC1 refuses to serve it when authorization
is disabled. Because IRC2 vends storage credentials for the service account
rather than for the calling user, such a catalog also always issues storage
credentials through Gravitino, as described below.
+
+| Configuration item | Description
| Default value | Required
|
+|-------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|---------------|---------------------------------------------|
+| `gravitino.iceberg-rest.rest-backend-auth-type` | How IRC1
authenticates to IRC2. `user-token` forwards the calling user's access token.
`service-account` connects with the credential below. | `user-token` |
No |
+| `gravitino.iceberg-rest.rest-backend-token` | Static bearer token
the service account presents to IRC2.
| (none) | One of token
or credential with `service-account` |
+| `gravitino.iceberg-rest.rest-backend-credential` | OAuth2 client
credential (`client_id:client_secret`) the service account exchanges for a
token. | (none) | One
of token or credential with `service-account` |
+| `gravitino.iceberg-rest.rest-backend-oauth2-server-uri` | OAuth2 token
endpoint for the client credential. Defaults to IRC2's own token endpoint.
| (none) | No
|
+| `gravitino.iceberg-rest.rest-backend-scope` | OAuth2 scope
requested with the client credential.
| (none) | No
|
+
+##### Gravitino-issued storage credentials
+
+By default IRC1 passes through the storage credentials IRC2 vends. Some
catalogs vend broad, long-lived credentials, for example the catalog token's
own storage keys scoped to the whole bucket. Set
`rest-backend-credential-vending` to `gravitino` and IRC1 stops asking IRC2 for
credentials. It issues them through its own `credential-providers` instead,
scoped to the table location, read-only unless the caller holds write
privileges on the table, exactly as for a local catalog. Credentials IRC2
returns unasked are dropped.
+
+| Configuration item | Description
| Default value | Required |
+|---------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|---------------|----------|
+| `gravitino.iceberg-rest.rest-backend-credential-vending` | Who issues
storage credentials for tables of the federated catalog. `remote` passes
through IRC2's credentials. `gravitino` uses `credential-providers`. A
`service-account` catalog always uses `gravitino`. | `remote` | No |
Review Comment:
`rest-backend-crendential-vending` makes me confused. We will think of a
better name.
--
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]
