Allow supplying a KmsClient instance/supplier instead of only a reflectively-instantiated class name
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Beginnen Sie damit, KeyToolkit.getKmsClient(...) und die bestehenden Reflection-Pfade von CryptoFactory, DecryptionPropertiesFactory und EncryptionPropertiesFactory zu lesen. Klären Sie mit den Maintainer:innen die bevorzugte API und den bevorzugten Speichermechanismus und fügen Sie anschließend Tests für einen bereitgestellten KmsClient ohne parameterlosen Konstruktor hinzu, wobei die reflektive Konstruktion und das Verhalten von initialize(...) erhalten bleiben.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Java
- Sterne
- 3.1k
- Forks
- 1.6k
- Ø Merge
- 4 T. 9 Std.
- Gemergte PRs (30 T.)
- 32
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/parquet-java
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
apache/parquet-java#3820 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Type: bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
apache/parquet-java#3792 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
apache/parquet-java#3767 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/parquet-java#3695 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
apache/parquet-java#3667 ·
Maintainer antworten meist innerhalb von 2 Tagen
Alle Issues in apache/parquet-java
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
refinedmods/refinedstorage2#1414 · 1 Kommentar ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
In Java's `LongBoundedSum`, setting `lower` to `Long.MIN_VALUE` under-estimates the sensitivityOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
google/differential-privacy#489 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
link-check link-check:manual
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100