LiJie20190102 commented on PR #13500:
URL: https://github.com/apache/gravitino/pull/13500#issuecomment-5854417884
> We'd better use something like KMS to solve this problem. Gravitino
already supports a pluggable secret manager solution. This is a more
industry-ready way.
Thanks for the suggestion @jerryshao! Agreed — I'll rework this to reuse the
existing pluggable `SecretProvider` SPI instead of introducing a standalone AES
mechanism.
**Revised approach: secret URN references in `gravitino.conf` + a built-in
file-based provider**
1. **Config values become secret URN references** instead of inline
`ENC(...)` ciphertext:
```properties
gravitino.entity.store.relational.jdbcPassword =
urn:gravitino-secret:file:server.jdbc.password
```
2. **New built-in `FileSecretsProvider`** (implements the existing
`SecretProvider` SPI, zero external dependencies): secrets live in a separate
encrypted keystore file (e.g. `conf/gravitino-secrets.conf`), encrypted with
AES-256-GCM + PBKDF2. The master key is supplied via the
`GRAVITINO_PASSWORD_ENCRYPTION_KEY` env var. `writeSecret` is unsupported — the
keystore is read-only at runtime and managed via CLI tooling.
3. **Existing infrastructure reused as-is** — `SecretManager`,
`SecretProviderRegistry`, and `SecretUrn` stay untouched. A small
`ConfigSecretResolver` resolves config values at the three JDBC password read
sites (`SqlSessionFactoryHelper`, `H2Database`, `StatisticManager`): URN →
`SecretManager.readSecret()`; plaintext → passthrough for backward
compatibility.
4. **CLI + Python tooling** to manage the keystore
(`set`/`get`/`delete`/`list`), cross-language interoperable.
5. **Threat model** (will be documented): the local file provider protects
against accidental credential exposure (config committed to git, backups,
screenshots) — it is not an access-control boundary. Users needing stronger
guarantees can later switch to an external secret manager (e.g. Vault) purely
by configuration, once such a provider is available — no code changes needed.
The default `jdbcPassword` stays plaintext `gravitino` — it's a publicly
known dev default, so encrypting it adds no real secrecy. Docs will guide
production deployments to set a custom master key and re-encrypt.
WDYT? Any concerns before I update the PR?
--
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]
