[jira] [Updated] (KUDU-1592) Documentation that mentions file block manager should sound more ominous
[ https://issues.apache.org/jira/browse/KUDU-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Bukor updated KUDU-1592: --- Fix Version/s: 1.8.0 Resolution: Fixed Status: Resolved (was: In Review) > Documentation that mentions file block manager should sound more ominous > > > Key: KUDU-1592 > URL: https://issues.apache.org/jira/browse/KUDU-1592 > Project: Kudu > Issue Type: Improvement > Components: documentation >Reporter: Todd Lipcon >Assignee: Attila Bukor >Priority: Major > Fix For: 1.8.0 > > > In troubleshooting.adoc, as well as in the error message when we fail to hole > punch, we suggest using the file block manager as a workaround. It says > something vague about "at the cost of some scalability and efficiency" but > should be something a lot more ominous -- users are quickly running out of > file descriptors if they try the FBM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KUDU-3423) Kudu can't handle multiple Ranger KMS servers
[ https://issues.apache.org/jira/browse/KUDU-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Bukor updated KUDU-3423: --- Fix Version/s: 1.17.0 Resolution: Fixed Status: Resolved (was: In Review) > Kudu can't handle multiple Ranger KMS servers > - > > Key: KUDU-3423 > URL: https://issues.apache.org/jira/browse/KUDU-3423 > Project: Kudu > Issue Type: Bug > Components: security >Affects Versions: 1.17.0 >Reporter: Attila Bukor >Assignee: Attila Bukor >Priority: Major > Fix For: 1.17.0 > > > It's possible to set up multiple Ranger KMS servers in HA, but Kudu is only > able to handle one as a key provider for data at rest encryption. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (KUDU-3385) Ranger KMS key provider
[ https://issues.apache.org/jira/browse/KUDU-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Bukor resolved KUDU-3385. Fix Version/s: 1.17.0 Resolution: Fixed > Ranger KMS key provider > --- > > Key: KUDU-3385 > URL: https://issues.apache.org/jira/browse/KUDU-3385 > Project: Kudu > Issue Type: Sub-task >Reporter: Attila Bukor >Assignee: Attila Bukor >Priority: Major > Fix For: 1.17.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (KUDU-2252) Design and implement native encryption at rest
[ https://issues.apache.org/jira/browse/KUDU-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Bukor resolved KUDU-2252. Fix Version/s: 1.17.0 Resolution: Fixed > Design and implement native encryption at rest > -- > > Key: KUDU-2252 > URL: https://issues.apache.org/jira/browse/KUDU-2252 > Project: Kudu > Issue Type: New Feature > Components: fs, security >Reporter: Mike Percy >Assignee: Attila Bukor >Priority: Major > Labels: roadmap-candidate > Fix For: 1.17.0 > > > It would be beneficial for Kudu to support native encryption at rest. > While the underlying filesystem can be encrypted with Kudu on top, there are > benefits to native encryption at rest: > * With native encryption support, it may be possible to specify different > encryption keys for different objects or object trees (such as is possible > with HDFS encryption) > * It may be possible to share a single block device with other storage, > including HDFS (note that some linux setups allow for "splitting" a device) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (KUDU-3392) Support custom certificate when Kudu acts as a client
[ https://issues.apache.org/jira/browse/KUDU-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Attila Bukor resolved KUDU-3392. Fix Version/s: 1.17.0 Resolution: Fixed > Support custom certificate when Kudu acts as a client > - > > Key: KUDU-3392 > URL: https://issues.apache.org/jira/browse/KUDU-3392 > Project: Kudu > Issue Type: Improvement >Reporter: Attila Bukor >Assignee: Attila Bukor >Priority: Major > Fix For: 1.17.0 > > > Kudu connects to Ranger KMS when encryption is enabled using libcurl, and if > the certificate is not trusted on the OS-level, it fails to connect. It > should be possible to trust a certificate file by providing it in the CLI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KUDU-1921) Add ability for clients to require authentication/encryption
[ https://issues.apache.org/jira/browse/KUDU-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733203#comment-17733203 ] ASF subversion and git services commented on KUDU-1921: --- Commit 6b2077e48e1e96cf6520db09ddd8c2d3ca97334d in kudu's branch refs/heads/master from Alexey Serbin [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=6b2077e48 ] [rpc] clean up JWT-related client-side negotiation code Since now there is an API to add a trusted TLS certificate into the chain of trusted certificates of a Kudu C++ client application, the test-only flag --jwt_client_require_trusted_tls_cert is no longer needed. This patch removes the flag along with corresponding test scenario. Correspondingly, the client now verifies the server's TLS certificate during TLS handshake since there isn't a case when a client would send out its JWT to a server it doesn't trust once the --jwt_client_require_trusted_tls_cert test-only flag is removed. This patch also adds an extra logging about a connection negotiation condition when the client has a JWT, but it doesn't trust the server's TLS certificate. In addition, I took the liberty of removing a few TODOs related to KUDU-1921 since the referred functionality has already been implemented. Change-Id: I85574ed05396fcf3740d9d068afa524cf125f5ff Reviewed-on: http://gerrit.cloudera.org:8080/20076 Reviewed-by: Attila Bukor Tested-by: Kudu Jenkins > Add ability for clients to require authentication/encryption > > > Key: KUDU-1921 > URL: https://issues.apache.org/jira/browse/KUDU-1921 > Project: Kudu > Issue Type: Improvement > Components: client, security >Affects Versions: 1.3.0 >Reporter: Todd Lipcon >Assignee: Attila Bukor >Priority: Critical > Labels: roadmap-candidate > Fix For: 1.16.0 > > > Currently, the clients always operate in "optional" mode for authentication > and encryption. This means that they are vulnerable to downgrade attacks by a > MITM. We should provide APIs so that clients can be configured to prohibit > downgrade when connecting to clusters they know to be secure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KUDU-3392) Support custom certificate when Kudu acts as a client
[ https://issues.apache.org/jira/browse/KUDU-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733214#comment-17733214 ] ASF subversion and git services commented on KUDU-3392: --- Commit 4734d6f167333e67483d45bbeaf7509180641414 in kudu's branch refs/heads/master from Alexey Serbin [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=4734d6f16 ] [util] KUDU-3392: add validator for --trusted_certificate_file While testing/troubleshooting the newly introduced JWT-based client authentication, I found that setting the flag to a non-existing file hadn't been handled as I expected. This patch addresses the issue, adding a validator for the flag. I didn't add any test to cover the newly added validator, but I have verified that it worked as expected in various scenarios w.r.t. the current value of the --trusted_certificate_file flag. This is a follow-up to 152211658ef9d33e0ad727ccba46f8af24cd45b0. Change-Id: I0d9d816a821a93037293d3985a2f577711d64ef2 Reviewed-on: http://gerrit.cloudera.org:8080/20075 Tested-by: Kudu Jenkins Reviewed-by: Attila Bukor > Support custom certificate when Kudu acts as a client > - > > Key: KUDU-3392 > URL: https://issues.apache.org/jira/browse/KUDU-3392 > Project: Kudu > Issue Type: Improvement >Reporter: Attila Bukor >Assignee: Attila Bukor >Priority: Major > Fix For: 1.17.0 > > > Kudu connects to Ranger KMS when encryption is enabled using libcurl, and if > the certificate is not trusted on the OS-level, it fails to connect. It > should be possible to trust a certificate file by providing it in the CLI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
