cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13971) Automatic certificate management using Vault
Date Tue, 21 Nov 2017 14:21:00 GMT

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

Jason Brown commented on CASSANDRA-13971:
-----------------------------------------

So, in order not to delay an initial discussion further, I'm reading the doc again and looking
at the posted code (not full out reviewing it, yet). The rub I keep hitting with this effort,
though, is that we are explicitly hitching the code base to a third party service (Vault).
While I'm sure the HashiCorp folks want to succeed, and want their Vault service to thrive,
I'm concerned about tying a portion of the core-database code to a service that could close
at any time. This, coupled with the recent talks of better pluggablity/SPI makes me wonder
if we should focus more on having a better plugin story around security and less on the the
Vault-integration pieces. 

Further, I'm worried that tying utests or dtests to Vault will be unnecessarily burdensome
for maintainers. For example, will we all need to have Vault accounts run the dtests? Would
all testing environments, in all private networks, need to access Vault to execute properly?
Is it possible to DDoS Vault just by running a full test integration suite, especially if
multiple maintainers/contributors run it at the same time?

I'm also reminded of the pig integration we had for a long time. While that was just an API,
and not actually connecting to any external service, it was onerous in the code base and hard
to know how many folks actually used it. (see CASSANDRA-10542)

To more positive comments, I'm pretty happy with what you've done in the branch to allow sources
for keys other than keystores. I think getting a solid API or SPI in place would be the best
first step here.

> Automatic certificate management using Vault
> --------------------------------------------
>
>                 Key: CASSANDRA-13971
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13971
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Streaming and Messaging
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>             Fix For: 4.x
>
>
> We've been adding security features during the last years to enable users to secure their
clusters, if they are willing to use them and do so correctly. Some features are powerful
and easy to work with, such as role based authorization. Other features that require to manage
a local keystore are rather painful to deal with. Think about setting up SSL..
> To be fair, keystore related issues and certificate handling hasn't been invented by
us. We're just following Java standards there. But that doesn't mean that we absolutely have
to, if there are better options. I'd like to give it a shoot and find out if we can automate
certificate/key handling (PKI) by using external APIs. In this case, the implementation will
be based on [Vault|https://vaultproject.io]. But certificate management services offered by
cloud providers may also be able to handle the use-case and I intend to create a generic,
pluggable API for that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message