szlta commented on code in PR #17155:
URL: https://github.com/apache/iceberg/pull/17155#discussion_r3672522059
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3665,6 +3676,43 @@ components:
additionalProperties:
type: string
+ 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:
I see your point, but this is not how Iceberg table encryption currently
works. The "old" keys you are referring to (aka those that encrypt snapshot
files) are internal to a table and not part of the KMS managed keyset.
Therefore those will never be part of the `key-management-credentials`.
Right now there's only one key per table in KMS which acts as the topmost
level KEK. The reason I'm referring to KMS keyS (so plural) is to allow future
column-level encryption in this spec.
--
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]
