nevzheng commented on issue #9836:
URL: https://github.com/apache/gravitino/issues/9836#issuecomment-5146345376
# [Epic] [Improvement] Configure TLS on the Gravitino Java client without
JVM-wide side effects
## Goal
An application can connect to a Gravitino server that uses the
organization's own
certificates — internal CA, mutual TLS — by configuring **that client
instance**,
without touching trust settings for anything else running in the same JVM.
Today the opposite is true: the Java client has no TLS configuration of its
own,
so the only lever is `javax.net.ssl.*` system properties or editing the JRE's
`cacerts`. Both are JVM-global. Setting a custom truststore to reach
Gravitino
*replaces* default trust — so it breaks every other TLS connection in the
process,
S3 clients being the canonical casualty. And `javax.net.ssl.keyStore` is a
single
property, so presenting different client certificates to different services
is
not expressible at all.
Iceberg hit exactly this and fixed it in apache/iceberg#13190 with a
pluggable
`TLSConfigurer` on the REST client. Gravitino has the same hole — made more
visible by the fact that Gravitino ships an Iceberg REST endpoint that
Iceberg
clients can now reach over private-PKI TLS, while Gravitino's own client
cannot.
One deliberate difference from Iceberg: their configurer loads via catalog
properties and reflection. Per review on #10975, ours is a typed builder
method —
properties can't give the client enough constraint.
## What success looks like
```java
GravitinoClient client =
GravitinoClient.builder("https://gravitino.internal:8433";)
.withMetalake("metalake")
.withTlsConfigurer(
TLSConfigurers.builder()
.trustStore(Path.of("/etc/pki/internal-ca.p12"), trustPassword)
.keyStore(Path.of("/etc/pki/service-client.p12"), keyPassword)
.build())
.build();
```
A few lines on the client, zero JVM flags, and nothing else in the process
affected.
## Critical user journeys
1. **Private-CA server** — verify a server whose certificate is signed by an
internal CA, without touching the JVM truststore.
2. **Mutual TLS** — present a client certificate to a server running with
`enableClientAuth=true`.
3. **Client certificate, publicly-trusted server** — present a client
certificate
while relying on the system truststore.
4. **Policy constraints** — restrict negotiated protocols or cipher suites
(e.g. enforce TLS 1.3).
1 and 2 are the core. 3 and 4 constrain the API design so they stay
reachable.
## Scope
- A `TLSConfigurer` contract and a helper for the common keystore/truststore
cases, exposed as a typed method on the client builders.
- Wiring through `HTTPClient` and the `GravitinoClient` /
`GravitinoAdminClient`
builders.
- Regression tests for server-side HTTPS and client authentication — the
server
has supported both since 0.3.0, but nothing covers it, and this work
depends on
that behavior holding.
- Documentation: replace the JVM-truststore instructions in
`docs/security/how-to-use-https.md` with the new API.
## Done when
- All four journeys are expressible in client code alone.
- Two clients in the same JVM can use different trust material and different
client certificates.
- Server-side HTTPS/mTLS behavior is CI-enforced.
- A client that configures nothing behaves exactly as today.
## Non-goals
- Server-side TLS changes — the server already does this; we only add
coverage.
- Certificate-based *authentication*. With `enableClientAuth`, the server
validates the client's certificate and then discards the identity; the
client
still authenticates via simple/OAuth/Kerberos. Deriving a Gravitino
principal
from the peer certificate is a natural follow-up, but it touches the
authenticator SPI and deserves its own epic. This one stops at trusted
transport.
- Python client parity — separate epic.
- Certificate provisioning, rotation, or secret management.
--
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]
