Skip to content

Make KMS key generation configurable for AwsKeyManagementClient and AliyunKeyManagementClient (currently always wraps) #18300

Open

Description

@mengna-lin

Feature Request / Improvement

Current behavior

AwsKeyManagementClient always uses wrapKey to create key encryption keys and never calls generateKey, even though AWS KMS supports server-side generation (GenerateDataKey) and the client implements it. The same behavior on Aliyun.

Proposal
Make it configurable on both Aliyun and AWS.

Query engine

None

Willingness to contribute

  • I can contribute this improvement/feature independently
  • I would be willing to contribute this improvement/feature with guidance from the Iceberg community
  • I cannot contribute this improvement/feature at this time

Activity

  1. changed the title [-]Make KMS key generation configurable for AwsKeyManagementClient (currently always wraps)[/-] [+]Make KMS key generation configurable for AwsKeyManagementClient and AliyunKeyManagementClient (currently always wraps)[/+] on Sep 28, 2026
  2. abhishekmauryaKsolves commented on Sep 30, 2026

    @abhishekmauryaKsolves

    Hi, I'd like to work on the AWS part of this. My plan: add a config property (e.g. kms.client.aws.key-generation-enabled) read in AwsKeyManagementClient.initialize() and use it in supportsKeyGeneration(). Two questions: (1) what should the property name and default be? #18210 uses kms.client.aliyun.key.generation.enabled with default true, but keeping false would preserve current AWS behavior. (2) Should Aliyun be handled in #18210 or as a follow-up after it merges?

  3. mengna-lin commented on Sep 30, 2026

    @mengna-lin
    ContributorAuthor

    Hi, I'd like to work on the AWS part of this. My plan: add a config property (e.g. kms.client.aws.key-generation-enabled) read in AwsKeyManagementClient.initialize() and use it in supportsKeyGeneration(). Two questions: (1) what should the property name and default be? #18210 uses kms.client.aliyun.key.generation.enabled with default true, but keeping false would preserve current AWS behavior. (2) Should Aliyun be handled in #18210 or as a follow-up after it merges?

    Hi,
    Thanks for taking the AWS part.

    1. I agree keeping false to preserve the current AWS behavior. Do you think if encryption.kek-generation-enabled is ok? It is in same format of encryption.key-id.
    2. I can create a separate PR after Aliyun: Add AliyunKeyManagementClient for client-side encryption #18210 is merged on Aliyun.
  4. abhishekmauryaKsolves commented on Oct 1, 2026

    @abhishekmauryaKsolves

    Thanks! encryption.kek-generation-enabled with default false sounds good to me.

    I'll open a PR for the AWS part only, and leave Aliyun to you after #18210 merges.

  5. abhishekmauryaKsolves commented on Oct 1, 2026

    @abhishekmauryaKsolves

    Thanks! Looking at the code, AwsKeyManagementClient.supportsKeyGeneration() already returns true, and the KEK is always created via wrapKey in StandardEncryptionManager. So my plan is to add encryption.kek-generation-enabled (default false) to TableProperties and use it in StandardEncryptionManager: when enabled and the client supportsKeyGeneration(), call generateKey() instead of wrapKey(). This would apply to any KeyManagementClient, not only AWS. Does that match what you had in mind?

  6. abhishekmauryaKsolves commented on Oct 1, 2026

    @abhishekmauryaKsolves

    Opened #18337 for this. Note it adds the table property in core, so the generation path is available to any KeyManagementClient, not just AWS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    improvementPR that improves existing functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions