[ 
https://issues.apache.org/jira/browse/KUDU-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737361#comment-17737361
 ] 

ASF subversion and git services commented on KUDU-3448:
-------------------------------------------------------

Commit 61d2296783a8392763f088d65a03376eb3e6463b in kudu's branch 
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=61d229678 ]

KUDU-3448 Add support for encrypting existing keys

On an existing cluster before KUDU-3448, the IPKI and TSK private keys
were stored in clear text. With KUDU-3448, it is now possible to encrypt
these keys, but without this commit, it's not possible to use this
feature in an existing cluster.

This commit introduces a fallback when trying to decrypt the stored
private keys, so that if that fails, it tries to read it without
decrypting it.

If it succeeds to read the IPKI private key, it encrypts it using the
password, and rewrites it in the sys-catalog table. It does no such
thing with the TSK, as they will be rolled out soon anyway, but it
encrypts the new keys, so it's still not possible to go back from
encrypted TSKs after a new key has been generated.

This commit doesn't make it possible to rotate the IPKI key.

Change-Id: Ide6ec4fb86325897f2b011aee9643d276044279d
Reviewed-on: http://gerrit.cloudera.org:8080/20050
Reviewed-by: Alexey Serbin <ale...@apache.org>
Tested-by: Alexey Serbin <ale...@apache.org>


> Store IPKI and TSK key material encrypted
> -----------------------------------------
>
>                 Key: KUDU-3448
>                 URL: https://issues.apache.org/jira/browse/KUDU-3448
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: Attila Bukor
>            Assignee: Attila Bukor
>            Priority: Critical
>              Labels: security
>
> Key material for IPKI TLS and TSK should be stored on disk securely, even 
> when user data is not encrypted. The symmetric encryption key should be 
> derived from a password using PBKDF2 which is a FIPS-approved KDF. The 
> masters should have a flag that expects a command which outputs the password 
> (similar to {{{}--webserver_private_key_password_cmd{}}}), that way the users 
> can integrate with a HSM or choose another way to provide the password 
> securely without storing it on a disk.
> Generating new keys or encrypting existing key material is outside the scope 
> of this ticket.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to