smaheshwar-pltr commented on code in PR #17155:
URL: https://github.com/apache/iceberg/pull/17155#discussion_r4287553361
##########
open-api/rest-catalog-open-api.py:
##########
@@ -791,10 +791,44 @@ class Sha256QueryLocal(Action):
action: Literal['sha-256-query-local']
+class KeyManagementCredential(BaseModel):
+ """
+ Provider-specific credential config for accessing one or more KMS keys
required by an encrypted
+ table operation.
+
+ The key-management provider is advertised in catalog configuration, such
as `encryption.kms-type`
+ returned from `/v1/config`. The `config` map contains provider-specific
properties for the
+ selected key-management provider.
Review Comment:
I think it's valuable to support per-table too, cc @singhpk234 for thoughts
too.
I noted the design doc's argument for keeping it catalog-level because
that's how it works today. But then I'd say: sure, one KMS per catalog is what
we have with e.g. Hive, but there *storage access* is also configured per
(client-side) catalog. REST permits storage access to per-table, and I think
same applies to KMS, so the argument isn't that strong IMO.
I wonder if the catalog-wide default you mention is then just a regular
catalog property. Like, IIRC (could be wrong) `/config` can already return
something like `io-impl` as a default and that works so wonder if we don't need
anything special there.
##########
open-api/rest-catalog-open-api.py:
##########
@@ -791,10 +791,44 @@ class Sha256QueryLocal(Action):
action: Literal['sha-256-query-local']
+class KeyManagementCredential(BaseModel):
+ """
+ Provider-specific credential config for accessing one or more KMS keys
required by an encrypted
+ table operation.
+
+ The key-management provider is advertised in catalog configuration, such
as `encryption.kms-type`
+ returned from `/v1/config`. The `config` map contains provider-specific
properties for the
+ selected key-management provider.
Review Comment:
I think it's valuable to support per-table too, cc @singhpk234 for thoughts
also.
I noted the design doc's argument for keeping it catalog-level because
that's how it works today. But then I'd say: sure, one KMS per catalog is what
we have with e.g. Hive, but there *storage access* is also configured per
(client-side) catalog. REST permits storage access to per-table, and I think
same applies to KMS, so the argument isn't that strong IMO.
I wonder if the catalog-wide default you mention is then just a regular
catalog property. Like, IIRC (could be wrong) `/config` can already return
something like `io-impl` as a default and that works so wonder if we don't need
anything special there.
--
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]
