> On Nov. 18, 2024, 4:27 a.m., bhavik patel wrote: > > Add couple of UTs?
Hi Bhavik, I checked for UTs. We don't have UTs at API level, existing UTs have been written to validate master key and Keyprovider. This code change is simply reusing the existing one. However, I am planning to create and raise PR in "hadoop-common" for KMSClientProvider to integrate this easily by using KMSClientProvider. - Vikas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75272/#review227067 ----------------------------------------------------------- On Nov. 14, 2024, 2:42 p.m., Vikas Kumar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/75272/ > ----------------------------------------------------------- > > (Updated Nov. 14, 2024, 2:42 p.m.) > > > Review request for ranger, bhavik patel, Dhaval Shah, Madhan Neethiraj, > Pradeep Agrawal, and Sailaja Polavarapu. > > > Repository: ranger > > > Description > ------- > > RANGER-3641: New KMS API to generate EDEK and DEK in one requestto avoid two > trips to KMS > > Many times client app creates EDEK when they need to encrypt any data. And at > that time, they need to make one call to get EDEK and subsequent call to > decrypt that EDEK to get plain DEK. And there it makes sense to have one API > that should return both EDEK and DEK together. > > I saw similar API in AWS KMS API, it returns both. > > Existing generateEncryptionkey is still there, and can be used for bulk EDEK > generation, may be for not immediate consumption, or to keep in client > caching and decrypt it when required. > > > Diffs > ----- > > kms/src/main/java/org/apache/hadoop/crypto/key/kms/server/KMS.java > 5bc0e7132 > > > Diff: https://reviews.apache.org/r/75272/diff/1/ > > > Testing > ------- > > Testing: > > 1. KMS build command is successful > 2. I patched one of my internal cluster with dev jar ( that contains this > code) and performed following operation: > > Step1: Create one Zone key, "dektestkey" > Step2: Hit the new API to generate EDEK and corresponding DEK > Request: > > curl -ivk -H "Content-Type: application/json" -H -X GET > 'http://apacheprtest.site:9292/kms/v1/key/dektestkey/_dek?user.name=keyadmin' > > Response: > > { > "edek" : { > "encryptedKeyVersion" : { > "material" : "gsndrW4VzpnTsC3PHC7sjw", > "name" : "dektestkey", > "versionName" : "EEK" > }, > "versionName" : "dektestkey@0", > "iv" : "S4FpjpscEhf6ELWKRTG8OQ" > }, > "dek" : { > "material" : "WiKLo1A79s-cGW5Sbb8pSw", > "name" : "dektestkey", > "versionName" : "EK" > } > } > > Step3: To cross check, I hit the existing decryptkey API with above EDEK > material and got the same DEK. > > Req: > curl -ivk -H "Content-Type: application/json" -H -X POST --data > '{"name":"dektestkey","iv":"S4FpjpscEhf6ELWKRTG8OQ","material":"gsndrW4VzpnTsC3PHC7sjw"}' > > 'http://ccycloud-1.dektest.root.comops.site:9292/kms/v1/keyversion/dektestkey@0/_eek?eek_op=decrypt&user.name=keyadmin' > > > Res: > { > "material" : "WiKLo1A79s-cGW5Sbb8pSw", > "name" : "dektestkey", > "versionName" : "EK" > > } > > > Thanks, > > Vikas Kumar > >
