LiJie20190102 opened a new issue, #14396:
URL: https://github.com/apache/gravitino/issues/14396
### Describe the proposal
Gravitino's entity secrets support (#12252) shipped the `SecretProvider` SPI
and the
`urn:gravitino-secret` reference model, but only a test-only in-memory
provider — production
deployments have no durable, encrypted secret backend, and sensitive server
configuration
values such as `gravitino.entity.store.relational.jdbcPassword` sit in
cleartext in
`gravitino.conf`. This epic implements KMS-backed secret encryption with
envelope encryption:
a KMS-wrapped master key, the KMS contacted once per process start, the hot
path local AES.
Design doc: `design-docs/gravitino-secret-encryption.md` (#13756).
Motivation: #13755.
Components:
- **Seal SPI.** A new `wrap`/`unwrap` interface, separate from the read-only
`KmsClient`,
with a `local` implementation for development/tests and cloud KMS
implementations for
production.
- **KMS-protected master key.** Plaintext only in process memory, zeroed on
shutdown; at
rest only as a KMS-wrapped blob in `gravitino.conf`.
- **DB-backed `SecretProvider` (type `db`).** Secrets persisted as
AES-256-GCM ciphertext
(URN as AAD) in a new entity-store table; SPI, URN model and REST contract
unchanged.
- **Encrypted server configuration.** Sensitive values, starting with the
entity store JDBC
password, may be stored as ciphertext and are decrypted transparently at
startup.
Master key rotation, a `vault-transit` seal, and per-secret KMS calls are
follow-ups beyond
this epic.
#### Priorities and dependencies
P0 is the foundation and the core encrypted-storage value. P1 items are
production
hardening that does not gate P0: a deployment needs at least one cloud seal,
but each can
land independently. Priority indicates work order, not a release-completion
commitment.
| Task | Priority | Depends on |
|---|---|---|
| #13755 Design document | P0 | None. |
| #<id-2> Seal SPI with `local` implementation | P0 | #13755. |
| #<id-3> Master key bootstrap and operator tooling | P0 | #<id-2>. |
| #<id-5> DB-backed `SecretProvider` | P0 | #<id-2>, #<id-3>. May proceed in
parallel with #<id-4>. |
| #<id-4> Encrypted server configuration | P0 | #<id-2>, #<id-3>. May
proceed in parallel with #<id-5>. |
| #<id-6> AWS KMS seal implementation | P1 | #<id-2>. Independent of
#<id-3>~#<id-5>; may proceed in parallel. |
| #<id-7> GCP Cloud KMS seal implementation | P1 | #<id-2>. Independent of
#<id-6>; may proceed in parallel. |
### Task list
**Foundation**
- [ ] **P0** #13755 Design document: KMS-backed secret encryption.
- [ ] **P0** #<id-2> Seal SPI (`SealClient`) with registry and `local`
implementation.
- [ ] **P0** #<id-3> Master key bootstrap: unwrap at startup,
`MasterKeyHolder`, operator tooling.
**Encrypted storage**
- [ ] **P0** #<id-5> DB-backed `SecretProvider` (type `db`) storing AES-GCM
ciphertext.
- [ ] **P0** #<id-4> Encrypted server configuration values (JDBC password
first).
**Cloud seal implementations**
- [ ] **P1** #<id-6> AWS KMS seal implementation.
- [ ] **P1** #<id-7> GCP Cloud KMS seal implementation.
Execution order: #13755 -> #<id-2> -> #<id-3> -> #<id-4>/#<id-5>;
#<id-6>/#<id-7> any time
after #<id-2>.
--
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]
