+1 (non-binding) Thanks Aravind, glad to see this shaped into a CIP. The client-side approach has real advantages - sendfile path stays intact, workers stay out of key handling, clean Spark integration.
Worth flagging for the record that CIP-22 is narrower than CELEBORN-2311 <https://issues.apache.org/jira/browse/CELEBORN-2311> it's Spark-only (Flink/MR clients uncovered), and spark.io.encryption derives keys locally with no KEK/DEK split or external custody - which is the part that matters for the HIPAA/PCI/SOC 2/FedRAMP deployments I had in mind. The KeyService SPI with pluggable KMS providers from CELEBORN-2311 is still needed for those. Suggest landing this as the Spark path and keeping CELEBORN-2311 open as the umbrella for the engine-agnostic worker-side track. Happy to drive that once this lands. - Karthik On Wed, May 6, 2026 at 10:16 AM Mridul Muralidharan <[email protected]> wrote: > +1 > > This is based on what we are currently in the process of rolling out > internally in production. > > Regards, > Mridul > > On Wed, May 6, 2026 at 1:53 AM Aravind Patnam <[email protected]> > wrote: > > > Hi all, > > > > This is a call to vote to contribute CIP 22: Encryption at Rest for > > Celeborn Shuffle Data > > < > > > https://docs.google.com/document/d/1xBrLtpb8bk8CdJENiM3aLJCbFThRKLor8uAjSsfXoxE/edit?usp=sharing > > >to > > Apache Celeborn. > > > > Please do vote accordingly: > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and the reason) > > > > Thanks once again!! > > > > -- > > Aravind K. Patnam > > > -- Thanks, Karthik
