xanderbailey commented on code in PR #17155:
URL: https://github.com/apache/iceberg/pull/17155#discussion_r4234875876
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4160,6 +4171,43 @@ components:
type: string
const: "sha-256-query-local"
+ KeyManagementCredential:
+ type: object
+ description: |
+ 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.
+
+ Catalogs that return `key-management-credentials` for an operation
must include credentials for all
+ KMS key IDs required by table encryption metadata. Clients should
select the credential config by
Review Comment:
Small clarity point: not every encrypted-by-id in table encryption metadata
is a KMS key ID. For example, manifest list keys have an encrypted-by-id
pointing to a KEK's key-id in encryption-keys, which is all internal. Only the
KEK entries' encrypted-by-id references the KMS master key (i.e.
encryption.key-id). Could we say explicitly that KMS credentials are only
needed for the keys that wrap KEKs, and that clients should match against those
rather than any encrypted-by-id?
Is there some wording that makes this more clear whilst not loosing
generality? I think this still carries in general if we later have more than
one? It would still be the key of a wrapped KEK?
--
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]
