[
https://issues.apache.org/jira/browse/RANGER-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kirby zhou updated RANGER-3682:
-------------------------------
Description:
Unify the ways that rangerkeystore to encapsulate zonekey
Now we have 2 styles of MasterKeyProvider:
# RangerMasterKey, RangerHSM, RangerSafenetKeySecure
# RangerAzureKeyVaultKeyGenerator, RangerGoogleCloudHSMProvider,
RangerTencentKMSProvider
Style 1 can get out master key string from provider, Style 2 can not.
In old, I add a flag KeyVaultEnabled to distinguish them. KeyVaultEnabled=false
means style1, true means style2
RangerKeyStore with style1 use SecretKeyEntry with SealedObject to store a key
and do encryption / decryption by itself.
RangerKeyStore with style2 use SecretKeyByteEntry to store a key and let MK
provider to encryption / decryption.
These logics are hard-coded in the class RangerKeyStore. These are ugly and
hard to maintain. I refactor it by removing SecretKeyEntry, and let providers
of style1 do encryption / decryption.
Add a common base class of RangerMasterKey, RangerHSM andd
RangerSafenetKeySecure, named AbstractRangerMasterKey. It provides the common
logic of encryptZoneKey and decryptZoneKey. AbstractRangerMasterKey encodes
SealedObject into byte[].
So the new code does not change the actual storage format, and there is no
problem in compatibility.
=====
And, there is no unified method to initialize a master key provider. Duplicate
code is distributed in RangerKeyStoreProvider and a bunch of CLI classes.
I made a new RangerKMSMKIFactory class to unify it.
was:
Unify the ways that rangerkeystore to encapsulate zonekey
Now we have 2 styles of MasterKeyProvider:
# RangerMasterKey, RangerHSM, RangerSafenetKeySecure
# RangerAzureKeyVaultKeyGenerator, RangerGoogleCloudHSMProvider,
RangerTencentKMSProvider
Style 1 can get out master key string from provider, Style 2 can not.
In old, I add a flag KeyVaultEnabled to distinguish them. KeyVaultEnabled=false
means style1, true means style2
RangerKeyStore with style1 use SecretKeyEntry with SealedObject to store a key
and do encryption / decryption by itself.
RangerKeyStore with style2 use SecretKeyByteEntry to store a key and let MK
provider to encryption / decryption.
These are ugly and hard to maintain. I refactor it by removing SecretKeyEntry,
and let providers of style1 do encryption / decryption.
Add a common base class of RangerMasterKey, RangerHSM andd
RangerSafenetKeySecure, named AbstractRangerMasterKey. It provides the common
logic of encryptZoneKey and decryptZoneKey. AbstractRangerMasterKey encodes
SealedObject into byte[].
So the new code does not change the actual storage format, and there is no
problem in compatibility.
=====
And, there is no unified method to initialize a master key provider. Duplicate
code is distributed in RangerKeyStoreProvider and a bunch of CLI classes.
I made a new RangerKMSMKIFactory class to unify it.
> Unify the ways that rangerkeystore to encapsulate zonekey
> ---------------------------------------------------------
>
> Key: RANGER-3682
> URL: https://issues.apache.org/jira/browse/RANGER-3682
> Project: Ranger
> Issue Type: Improvement
> Components: kms
> Affects Versions: 3.0.0, 2.3.0
> Reporter: kirby zhou
> Assignee: kirby zhou
> Priority: Major
>
> Unify the ways that rangerkeystore to encapsulate zonekey
> Now we have 2 styles of MasterKeyProvider:
> # RangerMasterKey, RangerHSM, RangerSafenetKeySecure
> # RangerAzureKeyVaultKeyGenerator, RangerGoogleCloudHSMProvider,
> RangerTencentKMSProvider
> Style 1 can get out master key string from provider, Style 2 can not.
> In old, I add a flag KeyVaultEnabled to distinguish them.
> KeyVaultEnabled=false means style1, true means style2
> RangerKeyStore with style1 use SecretKeyEntry with SealedObject to store a
> key and do encryption / decryption by itself.
> RangerKeyStore with style2 use SecretKeyByteEntry to store a key and let MK
> provider to encryption / decryption.
> These logics are hard-coded in the class RangerKeyStore. These are ugly and
> hard to maintain. I refactor it by removing SecretKeyEntry, and let providers
> of style1 do encryption / decryption.
> Add a common base class of RangerMasterKey, RangerHSM andd
> RangerSafenetKeySecure, named AbstractRangerMasterKey. It provides the common
> logic of encryptZoneKey and decryptZoneKey. AbstractRangerMasterKey encodes
> SealedObject into byte[].
> So the new code does not change the actual storage format, and there is no
> problem in compatibility.
> =====
>
> And, there is no unified method to initialize a master key provider.
> Duplicate code is distributed in RangerKeyStoreProvider and a bunch of CLI
> classes.
> I made a new RangerKMSMKIFactory class to unify it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
