GitHub user jianlirong added a comment to the discussion: [Ideas] data encrypt or privacy infomation protection
Thanks for opening this, @yz271544 — this is a topic I think a lot of users running Cloudberry in regulated environments (finance, healthcare, gov, etc.) would care about. A few questions to help turn this into something actionable: 1. Cloudberry already has two encryption layers: TDE (storage-engine-level encryption at rest) and `pgcrypto` (column-level encrypt/decrypt via SQL functions). How does the JWT-based approach relate to these — is it meant to sit *above* pgcrypto (managing/rotating the keys those functions use), or is it a separate, session-scoped mechanism? 2. On the JDBC/CLI session-level piece — could you sketch a concrete flow? E.g. client presents a JWT at connect time → coordinator validates it → derives a decryption key from a claim → result sets are transparently decrypted before being returned? That would clarify whether this is closer to a connection-level policy (like RLS) or in-transit re-encryption. 3. The inmod/outmod-style hooks for load/unload are interesting — the gpfdist/gpload path could plausibly support pluggable transform hooks. Does the teradata-cpt demo have a reference implementation for this part, or is it algorithm-only right now? 4. Would this be additive (new extension/contrib module) or does it need changes to core (parser/executor) to plumb JWT context through to the storage/output paths? That distinction matters a lot for scoping the work. If there's interest, it might be worth turning this into a short design doc. Lirong GitHub link: https://github.com/apache/cloudberry/discussions/1943#discussioncomment-18248079 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
