[
https://issues.apache.org/jira/browse/HDFS-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiao Chen updated HDFS-11210:
-----------------------------
Attachment: HDFS-11210.01.patch
Preliminary patch 1 to express the idea. This should take care of all things
KMS.
Regarding the last point about the provider instance (or specifically,
{{KeyProviderCryptoExtension}}) inside NN:
since no one else is aware of this client, I'm thinking when a re-encrypt
command is submitted, we need to get the keyname, and do a {{clearCache}}
always. Considering re-encrypt should be an infrequent command executed during
maintenance window, this should be acceptable. Better approaches welcome!
> Enhance key rolling to be atomic
> --------------------------------
>
> Key: HDFS-11210
> URL: https://issues.apache.org/jira/browse/HDFS-11210
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: encryption, kms
> Affects Versions: 2.6.5
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HDFS-11210.01.patch
>
>
> To support re-encrypting EDEK, we need to make sure after a key is rolled, no
> old version EDEKs are used anymore. This includes various caches when
> generating EDEK.
> This is not true currently, simply because no such requirements / necessities
> before.
> This includes
> - Client Provider(s), and corresponding cache(s).
> When LoadBalancingKMSCP is used, we need to clear all KMSCPs.
> - KMS server instance(s), and corresponding cache(s)
> When KMS HA is configured with multiple KMS instances, only 1 will receive
> the {{rollNewVersion}} request, we need to make sure other instances are
> rolled too.
> - The Client instance inside NN(s), and corresponding cache(s)
> When {{hadoop key roll}} is succeeded, the client provider inside NN should
> be drained too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
