Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Allow supplying a KmsClient instance/supplier instead of only a reflectively-instantiated class name

Fechada
  • Algo errado?
#3,683 5 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 4 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
java
Domínio
backend, security

Direção de pesquisa

Comece lendo KeyToolkit.getKmsClient(...) e os caminhos de reflexão existentes de CryptoFactory, DecryptionPropertiesFactory e EncryptionPropertiesFactory. Confirme com os maintainers a API e o mecanismo de armazenamento preferidos e, em seguida, adicione cobertura para um KmsClient fornecido que não tenha um construtor sem argumentos, preservando a construção reflexiva e o comportamento de initialize(...).

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Describe the enhancement requested

The key-tools KMS integration (org.apache.parquet.crypto.keytools) instantiates the KmsClient purely by reflection from a class name: KeyToolkit.getKmsClient(...) reads parquet.encryption.kms.client.class and calls newInstance(), requiring a public no-arg constructor, with credentials expected to arrive later via KmsClient.initialize(conf, kmsInstanceID, kmsInstanceURL, accessToken). The same reflective no-arg pattern applies to CryptoFactory / DecryptionPropertiesFactory / EncryptionPropertiesFactory via parquet.crypto.factory.class.

This works well when a KMS client is stateless and can bootstrap all of its credentials from the Configuration plus the access-token string. It does not work for clients that must be constructed with their dependencies and can't be reduced to a class name + string token, e.g.:

  • clients holding a live, credential-bearing SDK handle (federated / workload-identity credentials that aren't representable as a token string);
  • clients created and wired by a dependency-injection container;
  • in-memory / fake KMS clients used in tests, which carry per-test state and have no meaningful no-arg form.

For these, users must build a static side-channel: register the real instance in a static map keyed by a UUID written into the Configuration, point parquet.encryption.kms.client.class at a thin reflective shim that looks the instance back up in initialize(), and override parquet.encryption.kms.instance.id per instance to avoid colliding on KeyToolkit's per-(kmsInstanceID, accessToken) client cache. That's global mutable state with its own lifecycle/leak management and a one-Configuration-per-client invariant — boilerplate every such user reinvents.

Proposal. Add an opt-in, fully backward-compatible way to supply a pre-built KmsClient (or a Supplier<KmsClient> / small factory) programmatically, which KeyToolkit.getKmsClient(...) prefers over class-name reflection when present. Reflection stays the default, so existing configs are untouched. Rough shape (names TBD):

// today (still works):
conf.set("parquet.encryption.kms.client.class", "com.example.MyKmsClient");

// proposed addition:
KeyToolkit.setKmsClientFactory(conf, () -> myPreBuiltKmsClient); // or a KmsClientFactory

initialize(...) would still be invoked on the supplied instance, so credential/token plumbing is unchanged.

Scope / non-goals. No new dependencies and no vendor-specific code — this is only about how a KmsClient is provided, not which one. PropertiesDrivenCryptoFactory, the KeyMaterial format, caching, per-column keys, and key-rotation tooling are all unchanged; this only lifts the requirement that the client be reflectively no-arg constructible.

Question for maintainers. Would a change along these lines be welcome? And do you prefer (a) a Supplier<KmsClient> set on the Configuration / read-write options, or (b) a settable KmsClientFactory on KeyToolkit? Happy to implement it and open a PR (with tests using a non-no-arg client) once there's agreement on direction.

Component(s)

Core

Linguagem predominante
Java
Estrelas
3.1k
Forks
1.6k
Merge médio
5d 13h
PRs com merge (30d)
31

Preparar o ambiente

  • Sem Dockerfile nem arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/parquet-java

Todas as issues de apache/parquet-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.