[
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: [email protected]
For additional commands, e-mail: [email protected]
