[
https://issues.apache.org/jira/browse/KUDU-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782900#comment-17782900
]
ASF subversion and git services commented on KUDU-3522:
-------------------------------------------------------
Commit d4023e4af6c20d3185172df69540025c50c4e7ca in kudu's branch
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=d4023e4af ]
KUDU-3522 Fail early when encryption init fails
If encryption is enabled using --encrypt_data_at_rest, but the file
system was formatted without encryption enabled, Kudu would be unable to
bootstrap tablets as the encryption headers are missing, however, it
would still start happily without being able to host any tablets.
In some cases, for example when attempting to rebalance a cluster which
contain such "zombie" tablet servers, it can cause some cryptic error
message such as this:
Failed to initialize encryption: error:0607B083:digital envelope
routines:EVP_CipherInit_ex:no cipher set
This commit adds a check to the FS manager to disallow starting up with
encryption enabled and existing instance files without server keys to
address this issue as it's better to fail early in this case. It also
adds a regression test to verify it works as expected.
Change-Id: I7721953869452197f537b161bd6c6b095cc7e75f
Reviewed-on: http://gerrit.cloudera.org:8080/20651
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <[email protected]>
> A tablet server starts in non-functional state when enabling data-at-rest
> encryption
> ------------------------------------------------------------------------------------
>
> Key: KUDU-3522
> URL: https://issues.apache.org/jira/browse/KUDU-3522
> Project: Kudu
> Issue Type: Bug
> Components: security, tserver
> Affects Versions: 1.16.0, 1.17.0
> Reporter: Alexey Serbin
> Assignee: Attila Bukor
> Priority: Major
>
> It's possible to configure a Kudu tablet server by enabling the data-at-rest
> encryption feature in such a way that the server runs in a non-functional
> state: {{kudu-tserver}} process starts and runs with no visible issues, but
> it's not able to host any tablet replicas.
> It's easy to fix/address the issue by adding an extra sanity check: when
> opening an already existing FS data directory structure, make sure the server
> encryption key isn't empty if Kudu server is run with the
> {{\-\-encrypt_data_at_rest}} flag. There might be more alternatives around.
> The reproduction scenario for the issue is below.
> # Start a tablet server without encryption-at-rest, making sure the tablet
> server starts and creates the directory structure on the file system.
> # Don't create any tables/ranges yet. Essentially, it's necessary to make
> sure not a single tablet replica is placed at the server yet.
> # Shut down the tablet server.
> # Update the configuration for the tablet server, enabling
> encryption-at-rest and specifying the key provider. For test purposes, it's
> enough to use the "default" key provider:
> {noformat}
> --encrypt_data_at_rest=true
> --encryption_key_provider=default
> {noformat}
> # Start the tablet server.
> # Try to create a new tablet replica that would be placed at the tablet
> server. That could be creation of a new table, or try to move a tablet
> replica from some other tablet server by using the {{kudu tablet
> change_config move_replica}} CLI tool.
> # Check logs of Kudu master or the {{kudu}} CLI tool: there should be error
> messages like {{Failed to initialize encryption: error:0607B083:digital
> envelope routines:EVP_CipherInit_ex:no cipher set}}
> # No tablet replica can now be placed at the tablet server, while nothing
> suspicious can be found in the tablet server's log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
