GitHub user pavetheroad41 added a comment to the discussion: [Ideas] data encrypt or privacy infomation protection
Thanks for putting this together - data protection is a real gap for a lot of enterprise Cloudberry/Greenplum deployments, so it's good to see this raised. A few thoughts and questions on the proposal: Scope and threat model It would help to pin down what threat model this is targeting - encryption at rest (protecting data files/backups if storage is compromised), encryption in transit (already largely covered by TLS on JDBC/libpq), or column-level/application-layer encryption (protecting specific sensitive fields even from DB admins). The JWT + claims approach you're describing sounds closest to the third case, which has very different design constraints than TDE-style at-rest encryption. Prior art to consider pgcrypto already gives Postgres-family databases column-level encrypt/decrypt functions (pgp_sym_encrypt, etc.). Worth clarifying how this proposal differs - is the goal mainly to move key/claim management into a JWT-based session context rather than passing keys explicitly in SQL? Greenplum/Cloudberry's MPP architecture means encryption/decryption work needs to be pushed down to segments efficiently, not just the coordinator, this could get expensive at scale if not carefully implemented (e.g., per-row UDF calls). JWT-based key delivery Using a JWT claim to carry a decryption key (or a wrapped key) at session level is an interesting idea, but it raises questions: How would key rotation work? What's the failure mode if a token expires mid-session or mid-COPY? Would the key material touch server logs or EXPLAIN output anywhere? Load/export integration The fastload/fastexp-style inmod/outmod hooks are a reasonable model - Cloudberry's gpfdist/external table framework already has extensibility points that might map naturally onto this (custom protocol handlers or format functions) rather than requiring new machinery. Happy to help think through a design doc if there's interest in moving this forward, particularly around how this would interact with the segment/coordinator split and existing external table protocols. GitHub link: https://github.com/apache/cloudberry/discussions/1943#discussioncomment-18248233 ---- 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]
