[DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

There was a ticket created in (1) which wanted to make SSL context
creation pluggable / to fetch credentials remotely. I mentioned in (1)
that this is already possible to do as SSL context creation is
pluggable since CASSANDRA-16666.

The author of that ticket returned back saying that they used this
extensibility we provide (yay!) and they created an integration with
HashiCorp Vault (2).

Looking at the patch, there are no additional libraries /
dependencies, it just calls it via HTTP.

I want to ask if we can add this to the Cassandra codebase. While it
is a custom implementation and it is great that users integrate with
it, I think it is equally important to have this baked in so more
people can profit from this.

We already integrate various location providers
(AlibabaCloudLocationProvider, AzureCloudLocationProvider,
Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
is already a precedent in this kind of contributions which integrate
with external systems.

Are people OK with this?

Regards

(1) https://issues.apache.org/jira/browse/CASSANDRA-21153
(2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

Your assessment of the situation is mostly correct. I would just add
to that - if we extract and hide the plumbing behind some api /
methods, then for now we can just extract it to be reusable. We can
switch the internals to use some dedicated library later. We do not
need to do two things at once.

Since you will be the very first developer who is going to reuse this
outside of snitches, I think you have a great opportunity to shape how
it will look as you have a chance to get yourself pretty comfy on the
consumer side so you have an easy job there. I do not think it would
be good to pass on this.

I have created (1) where more detailed technical discussion can
happen, I would leave this thread for high-level discussion only.

Regards

(1) https://issues.apache.org/jira/browse/CASSANDRA-21195

On Mon, Mar 2, 2026 at 6:42 PM kumar bharath
<ku...@gmail.com> wrote:
>
> Hi Štefan/Josh McKenzie,
>
> Thanks for the note.
>
> I agree we should avoid introducing another independent low-level HTTP implementation in Cassandra. My intention in using plain HttpURLConnection was to stay consistent with Cassandra’s current approach and avoid bringing in an external HTTP client dependency.
>
> After reviewing AbstractCloudMetadataServiceConnector, it appears to be oriented toward metadata-style GET calls and specific response handling. The Vault AppRole flow, however, requires POST requests with a JSON body, custom headers, and consuming the response body even on non-success codes. Because of these differences, directly reusing that connector would not be a good fit.
>
> A more suitable approach may be to introduce a small shared HTTP utility (still based on HttpURLConnection) that can be used both by cloud metadata providers and by integrations such as this, rather than each component implementing its own connection/response handling.
>
> This would consolidate HTTP usage while keeping Cassandra dependency-free and provider-agnostic.
>
> Regards,
> Bharath Kumar B
>
>
> On Mon, Mar 2, 2026 at 11:08 AM Štefan Miklošovič <sm...@apache.org> wrote:
>>
>> Do not hesitate to ping us again if you want to help with spreading
>> the word / adoption! We can definitely advertise it on the website
>> among other tools.
>>
>> I can definitely see that a standalone project with extensions for
>> this functionality for each major cloud would attract a lot of
>> interest.
>>
>> Regards
>>
>> On Mon, Mar 2, 2026 at 5:54 PM kumar bharath
>> <ku...@gmail.com> wrote:
>> >
>> > Hi Maulin/Štefan,
>> >
>> > Thanks for the discussion and the suggestions.
>> >
>> > To clarify, the current implementation is HashiCorp Vault–specific and relies on Vault’s AppRole authentication and secret read semantics. There isn’t an S3-like common API across secret managers — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and in-house systems all expose different authentication models and response formats.
>> >
>> > In practice, some environments use HashiCorp Vault as a central secrets layer in front of cloud-specific secret stores, but that remains an operational choice and not something Cassandra itself should depend on directly.
>> >
>> > Based on your and Štefan’s comments, I agree it makes sense to continue developing this as a separate implementation using the existing ISslContextFactory extension point (referenced via cassandra.yaml). This keeps Cassandra core provider-agnostic while allowing integrations with Vault or other secret providers.
>> >
>> > We can evolve and validate the implementation externally, and once it matures and gains usage, we can revisit what should be included under the Cassandra umbrella.
>> >
>> > Thanks again for the guidance.
>> >
>> > Regards,
>> > Bharath Kumar B
>> >
>> >
>> > On Mon, Mar 2, 2026 at 9:33 AM Štefan Miklošovič <sm...@apache.org> wrote:
>> >>
>> >> So, the story behind that is that we have added Azure snitch (1) and
>> >> while doing so we consolidated a lot of stuff related to that. If you
>> >> look into 4.1, this HTTP custom thingy was there from
>> >> AlibabaCloudSnitch (2) so it was further built on.
>> >>
>> >> We have never replaced it with anything library-like. I guess mostly
>> >> because calling an endpoint was so easy / straightforward that what
>> >> was there was just enough.
>> >>
>> >> We have also not decided yet what it should be replaced with.
>> >>
>> >> (1) CASSANDRA-18646
>> >> (2) CASSANDRA-15092
>> >>
>> >> On Mon, Mar 2, 2026 at 3:52 PM Josh McKenzie <jm...@apache.org> wrote:
>> >> >
>> >> > there is very low-level stuff around HTTP. While I appreciate we do not use any libraries for that and it is plain Java,
>> >> >
>> >> > Acknowledging that I haven't taken a look at any code - is there a reason we're rolling our own vs. using off-the-shelf libs?
>> >> >
>> >> > On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
>> >> >
>> >> > Another point to add is that when I looked into the patch, there is
>> >> > very low-level stuff around HTTP. While I appreciate we do not use any
>> >> > libraries for that and it is plain Java, it would be way better to
>> >> > consolidate this usage, because we also talk via HTTP in cloud
>> >> > location providers (see e.g. AbstractCloudMetadataServiceConnector and
>> >> > its apiCall methods). So I can imagine that we would extract this code
>> >> > or accommodate it to be called from elsewhere, for cases like this. So
>> >> > the addition of this would be more complicated than just adding one
>> >> > class etc ...
>> >> >
>> >> > On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org> wrote:
>> >> > >
>> >> > > I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.
>> >> > >
>> >> > > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
>> >> > > >
>> >> > > > I gave it a second thought and I think that it would be better if the
>> >> > > > custom implementation lives in a completely separate repository for a
>> >> > > > while. Then a user would just put a jar on the class path of
>> >> > > > Cassandra, reference it in yaml and they could use this themselves.
>> >> > > >
>> >> > > > It is great that we see concrete implementations against what we made
>> >> > > > pluggable, indeed. But I think that there is basically no rush to make
>> >> > > > this part of Cassandra itself, at least for now. Because it is
>> >> > > > pluggable, the development can happen in isolation. To develop it in
>> >> > > > Cassandra directly has its own consequences I am not completely sure
>> >> > > > it is ideal to buy into right now.
>> >> > > >
>> >> > > > It is completely normal to develop extensions to Cassandra outside as
>> >> > > > separate projects. Then, once the solution is proven to be stable and
>> >> > > > mature and if there is ever such a need to have it in Cassandra
>> >> > > > directly, we can think about that. But developing it inside Cassandra,
>> >> > > > while it is extensible already, does not make immediate sense to me.
>> >> > > > These things use to take some time to stabilise and we might just
>> >> > > > bring instability while trying to do good.
>> >> > > >
>> >> > > > The separate project can also spend more time on AWS IAM integration
>> >> > > > etc. We can also mention this on Cassandra web page to spread the
>> >> > > > word. If the tooling is useful, people will discover it.
>> >> > > >
>> >> > > >
>> >> > > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
>> >> > > > <ma...@gmail.com> wrote:
>> >> > > >>
>> >> > > >> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
>> >> > > >>
>> >> > > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
>> >> > > >>>
>> >> > > >>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
>> >> > > >>>
>> >> > > >>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
>> >> > > >>>
>> >> > > >>> Thanks!
>> >> > > >>> Maulin
>> >> > > >>>
>> >> > > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
>> >> > > >>>>
>> >> > > >>>> Hi Stefan,
>> >> > > >>>>
>> >> > > >>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
>> >> > > >>>>
>> >> > > >>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
>> >> > > >>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
>> >> > > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
>> >> > > >>>>
>> >> > > >>>> Regards,
>> >> > > >>>> Bharath Kumar B
>> >> > > >>>>
>> >> > > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
>> >> > > >>>>>
>> >> > > >>>>> I want to add that while the proposed patch might work, it would be
>> >> > > >>>>> way better to integrate with this (1). The "problem" with the patch I
>> >> > > >>>>> see is that instead of storing passwords in cassandra.yaml (or in
>> >> > > >>>>> files we read from) we need yet another type of credential (vault role
>> >> > > >>>>> id / secret id) we also need to store somewhere. So the credentials
>> >> > > >>>>> are still around in some fashion. So instead of that, (1) enables you
>> >> > > >>>>> to get Vault token from EC2 instances. So there are truly no
>> >> > > >>>>> credentials stored on a Cassandra node which seems to be a way more
>> >> > > >>>>> robust solution.
>> >> > > >>>>>
>> >> > > >>>>> Maybe it would be better to welcome this type of contribution while
>> >> > > >>>>> proposing to "harden" this solution like proposed above? Or the patch
>> >> > > >>>>> might go in as well?
>> >> > > >>>>>
>> >> > > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>> >> > > >>>>>
>> >> > > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>> >> > > >>>>> <sm...@apache.org> wrote:
>> >> > > >>>>>>
>> >> > > >>>>>> There was a ticket created in (1) which wanted to make SSL context
>> >> > > >>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
>> >> > > >>>>>> that this is already possible to do as SSL context creation is
>> >> > > >>>>>> pluggable since CASSANDRA-16666.
>> >> > > >>>>>>
>> >> > > >>>>>> The author of that ticket returned back saying that they used this
>> >> > > >>>>>> extensibility we provide (yay!) and they created an integration with
>> >> > > >>>>>> HashiCorp Vault (2).
>> >> > > >>>>>>
>> >> > > >>>>>> Looking at the patch, there are no additional libraries /
>> >> > > >>>>>> dependencies, it just calls it via HTTP.
>> >> > > >>>>>>
>> >> > > >>>>>> I want to ask if we can add this to the Cassandra codebase. While it
>> >> > > >>>>>> is a custom implementation and it is great that users integrate with
>> >> > > >>>>>> it, I think it is equally important to have this baked in so more
>> >> > > >>>>>> people can profit from this.
>> >> > > >>>>>>
>> >> > > >>>>>> We already integrate various location providers
>> >> > > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>> >> > > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>> >> > > >>>>>> is already a precedent in this kind of contributions which integrate
>> >> > > >>>>>> with external systems.
>> >> > > >>>>>>
>> >> > > >>>>>> Are people OK with this?
>> >> > > >>>>>>
>> >> > > >>>>>> Regards
>> >> > > >>>>>>
>> >> > > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>> >> > > >>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>> >> > >
>> >> >
>> >> >

Re: [DISCUSS] HashiCorp Vault SSL Integration

[kumar bharath <ku...@gmail.com>]

Hi Štefan/Josh McKenzie,

Thanks for the note.

I agree we should avoid introducing another independent low-level HTTP
implementation in Cassandra. My intention in using plain HttpURLConnection
was to stay consistent with Cassandra’s current approach and avoid bringing
in an external HTTP client dependency.

After reviewing AbstractCloudMetadataServiceConnector, it appears to be
oriented toward metadata-style GET calls and specific response handling.
The Vault AppRole flow, however, requires POST requests with a JSON body,
custom headers, and consuming the response body even on non-success codes.
Because of these differences, directly reusing that connector would not be
a good fit.

A more suitable approach may be to introduce a small shared HTTP utility
(still based on HttpURLConnection) that can be used both by cloud metadata
providers and by integrations such as this, rather than each component
implementing its own connection/response handling.

This would consolidate HTTP usage while keeping Cassandra dependency-free
and provider-agnostic.

Regards,
Bharath Kumar B

On Mon, Mar 2, 2026 at 11:08 AM Štefan Miklošovič <sm...@apache.org>
wrote:

> Do not hesitate to ping us again if you want to help with spreading
> the word / adoption! We can definitely advertise it on the website
> among other tools.
>
> I can definitely see that a standalone project with extensions for
> this functionality for each major cloud would attract a lot of
> interest.
>
> Regards
>
> On Mon, Mar 2, 2026 at 5:54 PM kumar bharath
> <ku...@gmail.com> wrote:
> >
> > Hi Maulin/Štefan,
> >
> > Thanks for the discussion and the suggestions.
> >
> > To clarify, the current implementation is HashiCorp Vault–specific and
> relies on Vault’s AppRole authentication and secret read semantics. There
> isn’t an S3-like common API across secret managers — AWS Secrets Manager,
> Azure Key Vault, GCP Secret Manager, and in-house systems all expose
> different authentication models and response formats.
> >
> > In practice, some environments use HashiCorp Vault as a central secrets
> layer in front of cloud-specific secret stores, but that remains an
> operational choice and not something Cassandra itself should depend on
> directly.
> >
> > Based on your and Štefan’s comments, I agree it makes sense to continue
> developing this as a separate implementation using the existing
> ISslContextFactory extension point (referenced via cassandra.yaml). This
> keeps Cassandra core provider-agnostic while allowing integrations with
> Vault or other secret providers.
> >
> > We can evolve and validate the implementation externally, and once it
> matures and gains usage, we can revisit what should be included under the
> Cassandra umbrella.
> >
> > Thanks again for the guidance.
> >
> > Regards,
> > Bharath Kumar B
> >
> >
> > On Mon, Mar 2, 2026 at 9:33 AM Štefan Miklošovič <sm...@apache.org>
> wrote:
> >>
> >> So, the story behind that is that we have added Azure snitch (1) and
> >> while doing so we consolidated a lot of stuff related to that. If you
> >> look into 4.1, this HTTP custom thingy was there from
> >> AlibabaCloudSnitch (2) so it was further built on.
> >>
> >> We have never replaced it with anything library-like. I guess mostly
> >> because calling an endpoint was so easy / straightforward that what
> >> was there was just enough.
> >>
> >> We have also not decided yet what it should be replaced with.
> >>
> >> (1) CASSANDRA-18646
> >> (2) CASSANDRA-15092
> >>
> >> On Mon, Mar 2, 2026 at 3:52 PM Josh McKenzie <jm...@apache.org>
> wrote:
> >> >
> >> > there is very low-level stuff around HTTP. While I appreciate we do
> not use any libraries for that and it is plain Java,
> >> >
> >> > Acknowledging that I haven't taken a look at any code - is there a
> reason we're rolling our own vs. using off-the-shelf libs?
> >> >
> >> > On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
> >> >
> >> > Another point to add is that when I looked into the patch, there is
> >> > very low-level stuff around HTTP. While I appreciate we do not use any
> >> > libraries for that and it is plain Java, it would be way better to
> >> > consolidate this usage, because we also talk via HTTP in cloud
> >> > location providers (see e.g. AbstractCloudMetadataServiceConnector and
> >> > its apiCall methods). So I can imagine that we would extract this code
> >> > or accommodate it to be called from elsewhere, for cases like this. So
> >> > the addition of this would be more complicated than just adding one
> >> > class etc ...
> >> >
> >> > On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org>
> wrote:
> >> > >
> >> > > I agree with that, as it seems the provided patch is using the KV
> engine of vault to download JKS contents only. Which, however, is just one
> possibility to integrate vault. If you add this as “VaultSslContextFactory”
> and there comes another one along using e.g. the PKI engine or need to use
> PEM content, there will be at least a naming conflict. While I appreciate
> that this implementation is a valuable solution for a particular problem
> which may be faced by many, I don’t think this kind of glue-code should be
> part of the core repository.
> >> > >
> >> > > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <
> smiklosovic@apache.org> wrote:
> >> > > >
> >> > > > I gave it a second thought and I think that it would be better if
> the
> >> > > > custom implementation lives in a completely separate repository
> for a
> >> > > > while. Then a user would just put a jar on the class path of
> >> > > > Cassandra, reference it in yaml and they could use this
> themselves.
> >> > > >
> >> > > > It is great that we see concrete implementations against what we
> made
> >> > > > pluggable, indeed. But I think that there is basically no rush to
> make
> >> > > > this part of Cassandra itself, at least for now. Because it is
> >> > > > pluggable, the development can happen in isolation. To develop it
> in
> >> > > > Cassandra directly has its own consequences I am not completely
> sure
> >> > > > it is ideal to buy into right now.
> >> > > >
> >> > > > It is completely normal to develop extensions to Cassandra
> outside as
> >> > > > separate projects. Then, once the solution is proven to be stable
> and
> >> > > > mature and if there is ever such a need to have it in Cassandra
> >> > > > directly, we can think about that. But developing it inside
> Cassandra,
> >> > > > while it is extensible already, does not make immediate sense to
> me.
> >> > > > These things use to take some time to stabilise and we might just
> >> > > > bring instability while trying to do good.
> >> > > >
> >> > > > The separate project can also spend more time on AWS IAM
> integration
> >> > > > etc. We can also mention this on Cassandra web page to spread the
> >> > > > word. If the tooling is useful, people will discover it.
> >> > > >
> >> > > >
> >> > > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> >> > > > <ma...@gmail.com> wrote:
> >> > > >>
> >> > > >> On second thought, if the suggested abstraction becomes closer
> to existing abstraction available, then Stefan's original suggestion of
> having Cloud provider specific implementations of existing abstraction make
> sense. We can have discussion on making HashiCorp's implementation
> available as part of Cassandra or not separately.
> >> > > >>
> >> > > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <
> maulin.vasavada@gmail.com> wrote:
> >> > > >>>
> >> > > >>> Looks like a good addition to me! I agree we could first
> implement a generic solution followed by cloud provider specific
> implementations. However, we should make the VaultSslContextFactory
> abstract to leave it optional to allow someone to integrate with a
> potential inhouse legacy solution for a Vault. We should have a concrete
> implementation that does have HashiCorp name in it based on that
> abstraction. What do you guys think?
> >> > > >>>
> >> > > >>> One clarification question for Bharath- I know you mentioned
> that this is a generic Vault integration but are there any HashiCorp
> specific things at all? I've not done any integration with HashiCorp Vault
> but I feel there are a lot of nuances in that area and less unification -
> e.g. I am not sure if there is a S3 API like standard- that exists for
> object storage, to bring all "vaults/secrets-manager" under one umbrella.
> Given that it would be better to have the above approach of abstraction for
> Vault and HashiCorp specific implementation.
> >> > > >>>
> >> > > >>> Thanks!
> >> > > >>> Maulin
> >> > > >>>
> >> > > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <
> kumar.bharathb023@gmail.com> wrote:
> >> > > >>>>
> >> > > >>>> Hi Stefan,
> >> > > >>>>
> >> > > >>>> Thank you for the feedback! The AWS IAM auth approach is a
> great idea, and I completely agree that it provides a stronger security
> posture for EC2-based deployments by eliminating credentials on the node.
> >> > > >>>>
> >> > > >>>> That said, the goal of this patch is to provide a generic,
> cloud-vendor-independent integration with HashiCorp Vault that works across
> AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is
> Vault's recommended auth method for machine-to-machine authentication in
> any infrastructure.
> >> > > >>>> I'd propose we use this patch as the foundation and add
> cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on
> contributions—either as separate implementations or as additional auth
> strategies within the same factory. This way, we can deliver a generic
> solution while we build out cloud-specific enhancements.
> >> > > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM
> auth enhancement if the community agrees this is the right direction.
> >> > > >>>>
> >> > > >>>> Regards,
> >> > > >>>> Bharath Kumar B
> >> > > >>>>
> >> > > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <
> smiklosovic@apache.org> wrote:
> >> > > >>>>>
> >> > > >>>>> I want to add that while the proposed patch might work, it
> would be
> >> > > >>>>> way better to integrate with this (1). The "problem" with the
> patch I
> >> > > >>>>> see is that instead of storing passwords in cassandra.yaml
> (or in
> >> > > >>>>> files we read from) we need yet another type of credential
> (vault role
> >> > > >>>>> id / secret id) we also need to store somewhere. So the
> credentials
> >> > > >>>>> are still around in some fashion. So instead of that, (1)
> enables you
> >> > > >>>>> to get Vault token from EC2 instances. So there are truly no
> >> > > >>>>> credentials stored on a Cassandra node which seems to be a
> way more
> >> > > >>>>> robust solution.
> >> > > >>>>>
> >> > > >>>>> Maybe it would be better to welcome this type of contribution
> while
> >> > > >>>>> proposing to "harden" this solution like proposed above? Or
> the patch
> >> > > >>>>> might go in as well?
> >> > > >>>>>
> >> > > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
> >> > > >>>>>
> >> > > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> >> > > >>>>> <sm...@apache.org> wrote:
> >> > > >>>>>>
> >> > > >>>>>> There was a ticket created in (1) which wanted to make SSL
> context
> >> > > >>>>>> creation pluggable / to fetch credentials remotely. I
> mentioned in (1)
> >> > > >>>>>> that this is already possible to do as SSL context creation
> is
> >> > > >>>>>> pluggable since CASSANDRA-16666.
> >> > > >>>>>>
> >> > > >>>>>> The author of that ticket returned back saying that they
> used this
> >> > > >>>>>> extensibility we provide (yay!) and they created an
> integration with
> >> > > >>>>>> HashiCorp Vault (2).
> >> > > >>>>>>
> >> > > >>>>>> Looking at the patch, there are no additional libraries /
> >> > > >>>>>> dependencies, it just calls it via HTTP.
> >> > > >>>>>>
> >> > > >>>>>> I want to ask if we can add this to the Cassandra codebase.
> While it
> >> > > >>>>>> is a custom implementation and it is great that users
> integrate with
> >> > > >>>>>> it, I think it is equally important to have this baked in so
> more
> >> > > >>>>>> people can profit from this.
> >> > > >>>>>>
> >> > > >>>>>> We already integrate various location providers
> >> > > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> >> > > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on)
> so there
> >> > > >>>>>> is already a precedent in this kind of contributions which
> integrate
> >> > > >>>>>> with external systems.
> >> > > >>>>>>
> >> > > >>>>>> Are people OK with this?
> >> > > >>>>>>
> >> > > >>>>>> Regards
> >> > > >>>>>>
> >> > > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> >> > > >>>>>> (2)
> https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
> >> > >
> >> >
> >> >
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

Do not hesitate to ping us again if you want to help with spreading
the word / adoption! We can definitely advertise it on the website
among other tools.

I can definitely see that a standalone project with extensions for
this functionality for each major cloud would attract a lot of
interest.

Regards

On Mon, Mar 2, 2026 at 5:54 PM kumar bharath
<ku...@gmail.com> wrote:
>
> Hi Maulin/Štefan,
>
> Thanks for the discussion and the suggestions.
>
> To clarify, the current implementation is HashiCorp Vault–specific and relies on Vault’s AppRole authentication and secret read semantics. There isn’t an S3-like common API across secret managers — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and in-house systems all expose different authentication models and response formats.
>
> In practice, some environments use HashiCorp Vault as a central secrets layer in front of cloud-specific secret stores, but that remains an operational choice and not something Cassandra itself should depend on directly.
>
> Based on your and Štefan’s comments, I agree it makes sense to continue developing this as a separate implementation using the existing ISslContextFactory extension point (referenced via cassandra.yaml). This keeps Cassandra core provider-agnostic while allowing integrations with Vault or other secret providers.
>
> We can evolve and validate the implementation externally, and once it matures and gains usage, we can revisit what should be included under the Cassandra umbrella.
>
> Thanks again for the guidance.
>
> Regards,
> Bharath Kumar B
>
>
> On Mon, Mar 2, 2026 at 9:33 AM Štefan Miklošovič <sm...@apache.org> wrote:
>>
>> So, the story behind that is that we have added Azure snitch (1) and
>> while doing so we consolidated a lot of stuff related to that. If you
>> look into 4.1, this HTTP custom thingy was there from
>> AlibabaCloudSnitch (2) so it was further built on.
>>
>> We have never replaced it with anything library-like. I guess mostly
>> because calling an endpoint was so easy / straightforward that what
>> was there was just enough.
>>
>> We have also not decided yet what it should be replaced with.
>>
>> (1) CASSANDRA-18646
>> (2) CASSANDRA-15092
>>
>> On Mon, Mar 2, 2026 at 3:52 PM Josh McKenzie <jm...@apache.org> wrote:
>> >
>> > there is very low-level stuff around HTTP. While I appreciate we do not use any libraries for that and it is plain Java,
>> >
>> > Acknowledging that I haven't taken a look at any code - is there a reason we're rolling our own vs. using off-the-shelf libs?
>> >
>> > On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
>> >
>> > Another point to add is that when I looked into the patch, there is
>> > very low-level stuff around HTTP. While I appreciate we do not use any
>> > libraries for that and it is plain Java, it would be way better to
>> > consolidate this usage, because we also talk via HTTP in cloud
>> > location providers (see e.g. AbstractCloudMetadataServiceConnector and
>> > its apiCall methods). So I can imagine that we would extract this code
>> > or accommodate it to be called from elsewhere, for cases like this. So
>> > the addition of this would be more complicated than just adding one
>> > class etc ...
>> >
>> > On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org> wrote:
>> > >
>> > > I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.
>> > >
>> > > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
>> > > >
>> > > > I gave it a second thought and I think that it would be better if the
>> > > > custom implementation lives in a completely separate repository for a
>> > > > while. Then a user would just put a jar on the class path of
>> > > > Cassandra, reference it in yaml and they could use this themselves.
>> > > >
>> > > > It is great that we see concrete implementations against what we made
>> > > > pluggable, indeed. But I think that there is basically no rush to make
>> > > > this part of Cassandra itself, at least for now. Because it is
>> > > > pluggable, the development can happen in isolation. To develop it in
>> > > > Cassandra directly has its own consequences I am not completely sure
>> > > > it is ideal to buy into right now.
>> > > >
>> > > > It is completely normal to develop extensions to Cassandra outside as
>> > > > separate projects. Then, once the solution is proven to be stable and
>> > > > mature and if there is ever such a need to have it in Cassandra
>> > > > directly, we can think about that. But developing it inside Cassandra,
>> > > > while it is extensible already, does not make immediate sense to me.
>> > > > These things use to take some time to stabilise and we might just
>> > > > bring instability while trying to do good.
>> > > >
>> > > > The separate project can also spend more time on AWS IAM integration
>> > > > etc. We can also mention this on Cassandra web page to spread the
>> > > > word. If the tooling is useful, people will discover it.
>> > > >
>> > > >
>> > > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
>> > > > <ma...@gmail.com> wrote:
>> > > >>
>> > > >> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
>> > > >>
>> > > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
>> > > >>>
>> > > >>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
>> > > >>>
>> > > >>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
>> > > >>>
>> > > >>> Thanks!
>> > > >>> Maulin
>> > > >>>
>> > > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
>> > > >>>>
>> > > >>>> Hi Stefan,
>> > > >>>>
>> > > >>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
>> > > >>>>
>> > > >>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
>> > > >>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
>> > > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
>> > > >>>>
>> > > >>>> Regards,
>> > > >>>> Bharath Kumar B
>> > > >>>>
>> > > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
>> > > >>>>>
>> > > >>>>> I want to add that while the proposed patch might work, it would be
>> > > >>>>> way better to integrate with this (1). The "problem" with the patch I
>> > > >>>>> see is that instead of storing passwords in cassandra.yaml (or in
>> > > >>>>> files we read from) we need yet another type of credential (vault role
>> > > >>>>> id / secret id) we also need to store somewhere. So the credentials
>> > > >>>>> are still around in some fashion. So instead of that, (1) enables you
>> > > >>>>> to get Vault token from EC2 instances. So there are truly no
>> > > >>>>> credentials stored on a Cassandra node which seems to be a way more
>> > > >>>>> robust solution.
>> > > >>>>>
>> > > >>>>> Maybe it would be better to welcome this type of contribution while
>> > > >>>>> proposing to "harden" this solution like proposed above? Or the patch
>> > > >>>>> might go in as well?
>> > > >>>>>
>> > > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>> > > >>>>>
>> > > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>> > > >>>>> <sm...@apache.org> wrote:
>> > > >>>>>>
>> > > >>>>>> There was a ticket created in (1) which wanted to make SSL context
>> > > >>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
>> > > >>>>>> that this is already possible to do as SSL context creation is
>> > > >>>>>> pluggable since CASSANDRA-16666.
>> > > >>>>>>
>> > > >>>>>> The author of that ticket returned back saying that they used this
>> > > >>>>>> extensibility we provide (yay!) and they created an integration with
>> > > >>>>>> HashiCorp Vault (2).
>> > > >>>>>>
>> > > >>>>>> Looking at the patch, there are no additional libraries /
>> > > >>>>>> dependencies, it just calls it via HTTP.
>> > > >>>>>>
>> > > >>>>>> I want to ask if we can add this to the Cassandra codebase. While it
>> > > >>>>>> is a custom implementation and it is great that users integrate with
>> > > >>>>>> it, I think it is equally important to have this baked in so more
>> > > >>>>>> people can profit from this.
>> > > >>>>>>
>> > > >>>>>> We already integrate various location providers
>> > > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>> > > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>> > > >>>>>> is already a precedent in this kind of contributions which integrate
>> > > >>>>>> with external systems.
>> > > >>>>>>
>> > > >>>>>> Are people OK with this?
>> > > >>>>>>
>> > > >>>>>> Regards
>> > > >>>>>>
>> > > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>> > > >>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>> > >
>> >
>> >

Re: [DISCUSS] HashiCorp Vault SSL Integration

[kumar bharath <ku...@gmail.com>]

Hi Maulin/Štefan,

Thanks for the discussion and the suggestions.

To clarify, the current implementation is HashiCorp Vault–specific and
relies on Vault’s AppRole authentication and secret read semantics. There
isn’t an S3-like common API across secret managers — AWS Secrets Manager,
Azure Key Vault, GCP Secret Manager, and in-house systems all expose
different authentication models and response formats.

In practice, some environments use HashiCorp Vault as a central secrets
layer in front of cloud-specific secret stores, but that remains an
operational choice and not something Cassandra itself should depend on
directly.

Based on your and Štefan’s comments, I agree it makes sense to continue
developing this as a separate implementation using the existing
ISslContextFactory extension point (referenced via cassandra.yaml). This
keeps Cassandra core provider-agnostic while allowing integrations with
Vault or other secret providers.

We can evolve and validate the implementation externally, and once it
matures and gains usage, we can revisit what should be included under the
Cassandra umbrella.

Thanks again for the guidance.

Regards,
Bharath Kumar B

On Mon, Mar 2, 2026 at 9:33 AM Štefan Miklošovič <sm...@apache.org>
wrote:

> So, the story behind that is that we have added Azure snitch (1) and
> while doing so we consolidated a lot of stuff related to that. If you
> look into 4.1, this HTTP custom thingy was there from
> AlibabaCloudSnitch (2) so it was further built on.
>
> We have never replaced it with anything library-like. I guess mostly
> because calling an endpoint was so easy / straightforward that what
> was there was just enough.
>
> We have also not decided yet what it should be replaced with.
>
> (1) CASSANDRA-18646
> (2) CASSANDRA-15092
>
> On Mon, Mar 2, 2026 at 3:52 PM Josh McKenzie <jm...@apache.org> wrote:
> >
> > there is very low-level stuff around HTTP. While I appreciate we do not
> use any libraries for that and it is plain Java,
> >
> > Acknowledging that I haven't taken a look at any code - is there a
> reason we're rolling our own vs. using off-the-shelf libs?
> >
> > On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
> >
> > Another point to add is that when I looked into the patch, there is
> > very low-level stuff around HTTP. While I appreciate we do not use any
> > libraries for that and it is plain Java, it would be way better to
> > consolidate this usage, because we also talk via HTTP in cloud
> > location providers (see e.g. AbstractCloudMetadataServiceConnector and
> > its apiCall methods). So I can imagine that we would extract this code
> > or accommodate it to be called from elsewhere, for cases like this. So
> > the addition of this would be more complicated than just adding one
> > class etc ...
> >
> > On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org>
> wrote:
> > >
> > > I agree with that, as it seems the provided patch is using the KV
> engine of vault to download JKS contents only. Which, however, is just one
> possibility to integrate vault. If you add this as “VaultSslContextFactory”
> and there comes another one along using e.g. the PKI engine or need to use
> PEM content, there will be at least a naming conflict. While I appreciate
> that this implementation is a valuable solution for a particular problem
> which may be faced by many, I don’t think this kind of glue-code should be
> part of the core repository.
> > >
> > > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org>
> wrote:
> > > >
> > > > I gave it a second thought and I think that it would be better if the
> > > > custom implementation lives in a completely separate repository for a
> > > > while. Then a user would just put a jar on the class path of
> > > > Cassandra, reference it in yaml and they could use this themselves.
> > > >
> > > > It is great that we see concrete implementations against what we made
> > > > pluggable, indeed. But I think that there is basically no rush to
> make
> > > > this part of Cassandra itself, at least for now. Because it is
> > > > pluggable, the development can happen in isolation. To develop it in
> > > > Cassandra directly has its own consequences I am not completely sure
> > > > it is ideal to buy into right now.
> > > >
> > > > It is completely normal to develop extensions to Cassandra outside as
> > > > separate projects. Then, once the solution is proven to be stable and
> > > > mature and if there is ever such a need to have it in Cassandra
> > > > directly, we can think about that. But developing it inside
> Cassandra,
> > > > while it is extensible already, does not make immediate sense to me.
> > > > These things use to take some time to stabilise and we might just
> > > > bring instability while trying to do good.
> > > >
> > > > The separate project can also spend more time on AWS IAM integration
> > > > etc. We can also mention this on Cassandra web page to spread the
> > > > word. If the tooling is useful, people will discover it.
> > > >
> > > >
> > > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> > > > <ma...@gmail.com> wrote:
> > > >>
> > > >> On second thought, if the suggested abstraction becomes closer to
> existing abstraction available, then Stefan's original suggestion of having
> Cloud provider specific implementations of existing abstraction make sense.
> We can have discussion on making HashiCorp's implementation available as
> part of Cassandra or not separately.
> > > >>
> > > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <
> maulin.vasavada@gmail.com> wrote:
> > > >>>
> > > >>> Looks like a good addition to me! I agree we could first implement
> a generic solution followed by cloud provider specific implementations.
> However, we should make the VaultSslContextFactory abstract to leave it
> optional to allow someone to integrate with a potential inhouse legacy
> solution for a Vault. We should have a concrete implementation that does
> have HashiCorp name in it based on that abstraction. What do you guys think?
> > > >>>
> > > >>> One clarification question for Bharath- I know you mentioned that
> this is a generic Vault integration but are there any HashiCorp specific
> things at all? I've not done any integration with HashiCorp Vault but I
> feel there are a lot of nuances in that area and less unification - e.g. I
> am not sure if there is a S3 API like standard- that exists for object
> storage, to bring all "vaults/secrets-manager" under one umbrella.  Given
> that it would be better to have the above approach of abstraction for Vault
> and HashiCorp specific implementation.
> > > >>>
> > > >>> Thanks!
> > > >>> Maulin
> > > >>>
> > > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <
> kumar.bharathb023@gmail.com> wrote:
> > > >>>>
> > > >>>> Hi Stefan,
> > > >>>>
> > > >>>> Thank you for the feedback! The AWS IAM auth approach is a great
> idea, and I completely agree that it provides a stronger security posture
> for EC2-based deployments by eliminating credentials on the node.
> > > >>>>
> > > >>>> That said, the goal of this patch is to provide a generic,
> cloud-vendor-independent integration with HashiCorp Vault that works across
> AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is
> Vault's recommended auth method for machine-to-machine authentication in
> any infrastructure.
> > > >>>> I'd propose we use this patch as the foundation and add
> cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on
> contributions—either as separate implementations or as additional auth
> strategies within the same factory. This way, we can deliver a generic
> solution while we build out cloud-specific enhancements.
> > > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth
> enhancement if the community agrees this is the right direction.
> > > >>>>
> > > >>>> Regards,
> > > >>>> Bharath Kumar B
> > > >>>>
> > > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <
> smiklosovic@apache.org> wrote:
> > > >>>>>
> > > >>>>> I want to add that while the proposed patch might work, it would
> be
> > > >>>>> way better to integrate with this (1). The "problem" with the
> patch I
> > > >>>>> see is that instead of storing passwords in cassandra.yaml (or in
> > > >>>>> files we read from) we need yet another type of credential
> (vault role
> > > >>>>> id / secret id) we also need to store somewhere. So the
> credentials
> > > >>>>> are still around in some fashion. So instead of that, (1)
> enables you
> > > >>>>> to get Vault token from EC2 instances. So there are truly no
> > > >>>>> credentials stored on a Cassandra node which seems to be a way
> more
> > > >>>>> robust solution.
> > > >>>>>
> > > >>>>> Maybe it would be better to welcome this type of contribution
> while
> > > >>>>> proposing to "harden" this solution like proposed above? Or the
> patch
> > > >>>>> might go in as well?
> > > >>>>>
> > > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
> > > >>>>>
> > > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> > > >>>>> <sm...@apache.org> wrote:
> > > >>>>>>
> > > >>>>>> There was a ticket created in (1) which wanted to make SSL
> context
> > > >>>>>> creation pluggable / to fetch credentials remotely. I mentioned
> in (1)
> > > >>>>>> that this is already possible to do as SSL context creation is
> > > >>>>>> pluggable since CASSANDRA-16666.
> > > >>>>>>
> > > >>>>>> The author of that ticket returned back saying that they used
> this
> > > >>>>>> extensibility we provide (yay!) and they created an integration
> with
> > > >>>>>> HashiCorp Vault (2).
> > > >>>>>>
> > > >>>>>> Looking at the patch, there are no additional libraries /
> > > >>>>>> dependencies, it just calls it via HTTP.
> > > >>>>>>
> > > >>>>>> I want to ask if we can add this to the Cassandra codebase.
> While it
> > > >>>>>> is a custom implementation and it is great that users integrate
> with
> > > >>>>>> it, I think it is equally important to have this baked in so
> more
> > > >>>>>> people can profit from this.
> > > >>>>>>
> > > >>>>>> We already integrate various location providers
> > > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> > > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so
> there
> > > >>>>>> is already a precedent in this kind of contributions which
> integrate
> > > >>>>>> with external systems.
> > > >>>>>>
> > > >>>>>> Are people OK with this?
> > > >>>>>>
> > > >>>>>> Regards
> > > >>>>>>
> > > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> > > >>>>>> (2)
> https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
> > >
> >
> >
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

So, the story behind that is that we have added Azure snitch (1) and
while doing so we consolidated a lot of stuff related to that. If you
look into 4.1, this HTTP custom thingy was there from
AlibabaCloudSnitch (2) so it was further built on.

We have never replaced it with anything library-like. I guess mostly
because calling an endpoint was so easy / straightforward that what
was there was just enough.

We have also not decided yet what it should be replaced with.

(1) CASSANDRA-18646
(2) CASSANDRA-15092

On Mon, Mar 2, 2026 at 3:52 PM Josh McKenzie <jm...@apache.org> wrote:
>
> there is very low-level stuff around HTTP. While I appreciate we do not use any libraries for that and it is plain Java,
>
> Acknowledging that I haven't taken a look at any code - is there a reason we're rolling our own vs. using off-the-shelf libs?
>
> On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
>
> Another point to add is that when I looked into the patch, there is
> very low-level stuff around HTTP. While I appreciate we do not use any
> libraries for that and it is plain Java, it would be way better to
> consolidate this usage, because we also talk via HTTP in cloud
> location providers (see e.g. AbstractCloudMetadataServiceConnector and
> its apiCall methods). So I can imagine that we would extract this code
> or accommodate it to be called from elsewhere, for cases like this. So
> the addition of this would be more complicated than just adding one
> class etc ...
>
> On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org> wrote:
> >
> > I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.
> >
> > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
> > >
> > > I gave it a second thought and I think that it would be better if the
> > > custom implementation lives in a completely separate repository for a
> > > while. Then a user would just put a jar on the class path of
> > > Cassandra, reference it in yaml and they could use this themselves.
> > >
> > > It is great that we see concrete implementations against what we made
> > > pluggable, indeed. But I think that there is basically no rush to make
> > > this part of Cassandra itself, at least for now. Because it is
> > > pluggable, the development can happen in isolation. To develop it in
> > > Cassandra directly has its own consequences I am not completely sure
> > > it is ideal to buy into right now.
> > >
> > > It is completely normal to develop extensions to Cassandra outside as
> > > separate projects. Then, once the solution is proven to be stable and
> > > mature and if there is ever such a need to have it in Cassandra
> > > directly, we can think about that. But developing it inside Cassandra,
> > > while it is extensible already, does not make immediate sense to me.
> > > These things use to take some time to stabilise and we might just
> > > bring instability while trying to do good.
> > >
> > > The separate project can also spend more time on AWS IAM integration
> > > etc. We can also mention this on Cassandra web page to spread the
> > > word. If the tooling is useful, people will discover it.
> > >
> > >
> > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> > > <ma...@gmail.com> wrote:
> > >>
> > >> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
> > >>
> > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
> > >>>
> > >>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
> > >>>
> > >>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
> > >>>
> > >>> Thanks!
> > >>> Maulin
> > >>>
> > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
> > >>>>
> > >>>> Hi Stefan,
> > >>>>
> > >>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
> > >>>>
> > >>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
> > >>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
> > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
> > >>>>
> > >>>> Regards,
> > >>>> Bharath Kumar B
> > >>>>
> > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
> > >>>>>
> > >>>>> I want to add that while the proposed patch might work, it would be
> > >>>>> way better to integrate with this (1). The "problem" with the patch I
> > >>>>> see is that instead of storing passwords in cassandra.yaml (or in
> > >>>>> files we read from) we need yet another type of credential (vault role
> > >>>>> id / secret id) we also need to store somewhere. So the credentials
> > >>>>> are still around in some fashion. So instead of that, (1) enables you
> > >>>>> to get Vault token from EC2 instances. So there are truly no
> > >>>>> credentials stored on a Cassandra node which seems to be a way more
> > >>>>> robust solution.
> > >>>>>
> > >>>>> Maybe it would be better to welcome this type of contribution while
> > >>>>> proposing to "harden" this solution like proposed above? Or the patch
> > >>>>> might go in as well?
> > >>>>>
> > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
> > >>>>>
> > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> > >>>>> <sm...@apache.org> wrote:
> > >>>>>>
> > >>>>>> There was a ticket created in (1) which wanted to make SSL context
> > >>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
> > >>>>>> that this is already possible to do as SSL context creation is
> > >>>>>> pluggable since CASSANDRA-16666.
> > >>>>>>
> > >>>>>> The author of that ticket returned back saying that they used this
> > >>>>>> extensibility we provide (yay!) and they created an integration with
> > >>>>>> HashiCorp Vault (2).
> > >>>>>>
> > >>>>>> Looking at the patch, there are no additional libraries /
> > >>>>>> dependencies, it just calls it via HTTP.
> > >>>>>>
> > >>>>>> I want to ask if we can add this to the Cassandra codebase. While it
> > >>>>>> is a custom implementation and it is great that users integrate with
> > >>>>>> it, I think it is equally important to have this baked in so more
> > >>>>>> people can profit from this.
> > >>>>>>
> > >>>>>> We already integrate various location providers
> > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
> > >>>>>> is already a precedent in this kind of contributions which integrate
> > >>>>>> with external systems.
> > >>>>>>
> > >>>>>> Are people OK with this?
> > >>>>>>
> > >>>>>> Regards
> > >>>>>>
> > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> > >>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
> >
>
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Josh McKenzie <jm...@apache.org>]

> there is very low-level stuff around HTTP. While I appreciate we do not use any libraries for that and it is plain Java,
Acknowledging that I haven't taken a look at any code - is there a reason we're rolling our own vs. using off-the-shelf libs?

On Mon, Mar 2, 2026, at 6:42 AM, Štefan Miklošovič wrote:
> Another point to add is that when I looked into the patch, there is
> very low-level stuff around HTTP. While I appreciate we do not use any
> libraries for that and it is plain Java, it would be way better to
> consolidate this usage, because we also talk via HTTP in cloud
> location providers (see e.g. AbstractCloudMetadataServiceConnector and
> its apiCall methods). So I can imagine that we would extract this code
> or accommodate it to be called from elsewhere, for cases like this. So
> the addition of this would be more complicated than just adding one
> class etc ...
> 
> On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org> wrote:
> >
> > I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.
> >
> > > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
> > >
> > > I gave it a second thought and I think that it would be better if the
> > > custom implementation lives in a completely separate repository for a
> > > while. Then a user would just put a jar on the class path of
> > > Cassandra, reference it in yaml and they could use this themselves.
> > >
> > > It is great that we see concrete implementations against what we made
> > > pluggable, indeed. But I think that there is basically no rush to make
> > > this part of Cassandra itself, at least for now. Because it is
> > > pluggable, the development can happen in isolation. To develop it in
> > > Cassandra directly has its own consequences I am not completely sure
> > > it is ideal to buy into right now.
> > >
> > > It is completely normal to develop extensions to Cassandra outside as
> > > separate projects. Then, once the solution is proven to be stable and
> > > mature and if there is ever such a need to have it in Cassandra
> > > directly, we can think about that. But developing it inside Cassandra,
> > > while it is extensible already, does not make immediate sense to me.
> > > These things use to take some time to stabilise and we might just
> > > bring instability while trying to do good.
> > >
> > > The separate project can also spend more time on AWS IAM integration
> > > etc. We can also mention this on Cassandra web page to spread the
> > > word. If the tooling is useful, people will discover it.
> > >
> > >
> > > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> > > <ma...@gmail.com> wrote:
> > >>
> > >> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
> > >>
> > >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
> > >>>
> > >>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
> > >>>
> > >>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
> > >>>
> > >>> Thanks!
> > >>> Maulin
> > >>>
> > >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
> > >>>>
> > >>>> Hi Stefan,
> > >>>>
> > >>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
> > >>>>
> > >>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
> > >>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
> > >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
> > >>>>
> > >>>> Regards,
> > >>>> Bharath Kumar B
> > >>>>
> > >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
> > >>>>>
> > >>>>> I want to add that while the proposed patch might work, it would be
> > >>>>> way better to integrate with this (1). The "problem" with the patch I
> > >>>>> see is that instead of storing passwords in cassandra.yaml (or in
> > >>>>> files we read from) we need yet another type of credential (vault role
> > >>>>> id / secret id) we also need to store somewhere. So the credentials
> > >>>>> are still around in some fashion. So instead of that, (1) enables you
> > >>>>> to get Vault token from EC2 instances. So there are truly no
> > >>>>> credentials stored on a Cassandra node which seems to be a way more
> > >>>>> robust solution.
> > >>>>>
> > >>>>> Maybe it would be better to welcome this type of contribution while
> > >>>>> proposing to "harden" this solution like proposed above? Or the patch
> > >>>>> might go in as well?
> > >>>>>
> > >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
> > >>>>>
> > >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> > >>>>> <sm...@apache.org> wrote:
> > >>>>>>
> > >>>>>> There was a ticket created in (1) which wanted to make SSL context
> > >>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
> > >>>>>> that this is already possible to do as SSL context creation is
> > >>>>>> pluggable since CASSANDRA-16666.
> > >>>>>>
> > >>>>>> The author of that ticket returned back saying that they used this
> > >>>>>> extensibility we provide (yay!) and they created an integration with
> > >>>>>> HashiCorp Vault (2).
> > >>>>>>
> > >>>>>> Looking at the patch, there are no additional libraries /
> > >>>>>> dependencies, it just calls it via HTTP.
> > >>>>>>
> > >>>>>> I want to ask if we can add this to the Cassandra codebase. While it
> > >>>>>> is a custom implementation and it is great that users integrate with
> > >>>>>> it, I think it is equally important to have this baked in so more
> > >>>>>> people can profit from this.
> > >>>>>>
> > >>>>>> We already integrate various location providers
> > >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> > >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
> > >>>>>> is already a precedent in this kind of contributions which integrate
> > >>>>>> with external systems.
> > >>>>>>
> > >>>>>> Are people OK with this?
> > >>>>>>
> > >>>>>> Regards
> > >>>>>>
> > >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> > >>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
> >
> 

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

Another point to add is that when I looked into the patch, there is
very low-level stuff around HTTP. While I appreciate we do not use any
libraries for that and it is plain Java, it would be way better to
consolidate this usage, because we also talk via HTTP in cloud
location providers (see e.g. AbstractCloudMetadataServiceConnector and
its apiCall methods). So I can imagine that we would extract this code
or accommodate it to be called from elsewhere, for cases like this. So
the addition of this would be more complicated than just adding one
class etc ...

On Mon, Mar 2, 2026 at 12:26 PM Tibor Répási <ti...@anzix.org> wrote:
>
> I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.
>
> > On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
> >
> > I gave it a second thought and I think that it would be better if the
> > custom implementation lives in a completely separate repository for a
> > while. Then a user would just put a jar on the class path of
> > Cassandra, reference it in yaml and they could use this themselves.
> >
> > It is great that we see concrete implementations against what we made
> > pluggable, indeed. But I think that there is basically no rush to make
> > this part of Cassandra itself, at least for now. Because it is
> > pluggable, the development can happen in isolation. To develop it in
> > Cassandra directly has its own consequences I am not completely sure
> > it is ideal to buy into right now.
> >
> > It is completely normal to develop extensions to Cassandra outside as
> > separate projects. Then, once the solution is proven to be stable and
> > mature and if there is ever such a need to have it in Cassandra
> > directly, we can think about that. But developing it inside Cassandra,
> > while it is extensible already, does not make immediate sense to me.
> > These things use to take some time to stabilise and we might just
> > bring instability while trying to do good.
> >
> > The separate project can also spend more time on AWS IAM integration
> > etc. We can also mention this on Cassandra web page to spread the
> > word. If the tooling is useful, people will discover it.
> >
> >
> > On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> > <ma...@gmail.com> wrote:
> >>
> >> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
> >>
> >> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
> >>>
> >>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
> >>>
> >>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
> >>>
> >>> Thanks!
> >>> Maulin
> >>>
> >>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
> >>>>
> >>>> Hi Stefan,
> >>>>
> >>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
> >>>>
> >>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
> >>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
> >>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
> >>>>
> >>>> Regards,
> >>>> Bharath Kumar B
> >>>>
> >>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
> >>>>>
> >>>>> I want to add that while the proposed patch might work, it would be
> >>>>> way better to integrate with this (1). The "problem" with the patch I
> >>>>> see is that instead of storing passwords in cassandra.yaml (or in
> >>>>> files we read from) we need yet another type of credential (vault role
> >>>>> id / secret id) we also need to store somewhere. So the credentials
> >>>>> are still around in some fashion. So instead of that, (1) enables you
> >>>>> to get Vault token from EC2 instances. So there are truly no
> >>>>> credentials stored on a Cassandra node which seems to be a way more
> >>>>> robust solution.
> >>>>>
> >>>>> Maybe it would be better to welcome this type of contribution while
> >>>>> proposing to "harden" this solution like proposed above? Or the patch
> >>>>> might go in as well?
> >>>>>
> >>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
> >>>>>
> >>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> >>>>> <sm...@apache.org> wrote:
> >>>>>>
> >>>>>> There was a ticket created in (1) which wanted to make SSL context
> >>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
> >>>>>> that this is already possible to do as SSL context creation is
> >>>>>> pluggable since CASSANDRA-16666.
> >>>>>>
> >>>>>> The author of that ticket returned back saying that they used this
> >>>>>> extensibility we provide (yay!) and they created an integration with
> >>>>>> HashiCorp Vault (2).
> >>>>>>
> >>>>>> Looking at the patch, there are no additional libraries /
> >>>>>> dependencies, it just calls it via HTTP.
> >>>>>>
> >>>>>> I want to ask if we can add this to the Cassandra codebase. While it
> >>>>>> is a custom implementation and it is great that users integrate with
> >>>>>> it, I think it is equally important to have this baked in so more
> >>>>>> people can profit from this.
> >>>>>>
> >>>>>> We already integrate various location providers
> >>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> >>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
> >>>>>> is already a precedent in this kind of contributions which integrate
> >>>>>> with external systems.
> >>>>>>
> >>>>>> Are people OK with this?
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> >>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Tibor Répási <ti...@anzix.org>]

I agree with that, as it seems the provided patch is using the KV engine of vault to download JKS contents only. Which, however, is just one possibility to integrate vault. If you add this as “VaultSslContextFactory” and there comes another one along using e.g. the PKI engine or need to use PEM content, there will be at least a naming conflict. While I appreciate that this implementation is a valuable solution for a particular problem which may be faced by many, I don’t think this kind of glue-code should be part of the core repository.

> On 1. Mar 2026, at 10:59, Štefan Miklošovič <sm...@apache.org> wrote:
> 
> I gave it a second thought and I think that it would be better if the
> custom implementation lives in a completely separate repository for a
> while. Then a user would just put a jar on the class path of
> Cassandra, reference it in yaml and they could use this themselves.
> 
> It is great that we see concrete implementations against what we made
> pluggable, indeed. But I think that there is basically no rush to make
> this part of Cassandra itself, at least for now. Because it is
> pluggable, the development can happen in isolation. To develop it in
> Cassandra directly has its own consequences I am not completely sure
> it is ideal to buy into right now.
> 
> It is completely normal to develop extensions to Cassandra outside as
> separate projects. Then, once the solution is proven to be stable and
> mature and if there is ever such a need to have it in Cassandra
> directly, we can think about that. But developing it inside Cassandra,
> while it is extensible already, does not make immediate sense to me.
> These things use to take some time to stabilise and we might just
> bring instability while trying to do good.
> 
> The separate project can also spend more time on AWS IAM integration
> etc. We can also mention this on Cassandra web page to spread the
> word. If the tooling is useful, people will discover it.
> 
> 
> On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
> <ma...@gmail.com> wrote:
>> 
>> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
>> 
>> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
>>> 
>>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
>>> 
>>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
>>> 
>>> Thanks!
>>> Maulin
>>> 
>>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
>>>> 
>>>> Hi Stefan,
>>>> 
>>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
>>>> 
>>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
>>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
>>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
>>>> 
>>>> Regards,
>>>> Bharath Kumar B
>>>> 
>>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
>>>>> 
>>>>> I want to add that while the proposed patch might work, it would be
>>>>> way better to integrate with this (1). The "problem" with the patch I
>>>>> see is that instead of storing passwords in cassandra.yaml (or in
>>>>> files we read from) we need yet another type of credential (vault role
>>>>> id / secret id) we also need to store somewhere. So the credentials
>>>>> are still around in some fashion. So instead of that, (1) enables you
>>>>> to get Vault token from EC2 instances. So there are truly no
>>>>> credentials stored on a Cassandra node which seems to be a way more
>>>>> robust solution.
>>>>> 
>>>>> Maybe it would be better to welcome this type of contribution while
>>>>> proposing to "harden" this solution like proposed above? Or the patch
>>>>> might go in as well?
>>>>> 
>>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>>>>> 
>>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>>>>> <sm...@apache.org> wrote:
>>>>>> 
>>>>>> There was a ticket created in (1) which wanted to make SSL context
>>>>>> creation pluggable / to fetch credentials remotely. I mentioned in (1)
>>>>>> that this is already possible to do as SSL context creation is
>>>>>> pluggable since CASSANDRA-16666.
>>>>>> 
>>>>>> The author of that ticket returned back saying that they used this
>>>>>> extensibility we provide (yay!) and they created an integration with
>>>>>> HashiCorp Vault (2).
>>>>>> 
>>>>>> Looking at the patch, there are no additional libraries /
>>>>>> dependencies, it just calls it via HTTP.
>>>>>> 
>>>>>> I want to ask if we can add this to the Cassandra codebase. While it
>>>>>> is a custom implementation and it is great that users integrate with
>>>>>> it, I think it is equally important to have this baked in so more
>>>>>> people can profit from this.
>>>>>> 
>>>>>> We already integrate various location providers
>>>>>> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>>>>>> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>>>>>> is already a precedent in this kind of contributions which integrate
>>>>>> with external systems.
>>>>>> 
>>>>>> Are people OK with this?
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>>>>>> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

I gave it a second thought and I think that it would be better if the
custom implementation lives in a completely separate repository for a
while. Then a user would just put a jar on the class path of
Cassandra, reference it in yaml and they could use this themselves.

It is great that we see concrete implementations against what we made
pluggable, indeed. But I think that there is basically no rush to make
this part of Cassandra itself, at least for now. Because it is
pluggable, the development can happen in isolation. To develop it in
Cassandra directly has its own consequences I am not completely sure
it is ideal to buy into right now.

It is completely normal to develop extensions to Cassandra outside as
separate projects. Then, once the solution is proven to be stable and
mature and if there is ever such a need to have it in Cassandra
directly, we can think about that. But developing it inside Cassandra,
while it is extensible already, does not make immediate sense to me.
These things use to take some time to stabilise and we might just
bring instability while trying to do good.

The separate project can also spend more time on AWS IAM integration
etc. We can also mention this on Cassandra web page to spread the
word. If the tooling is useful, people will discover it.


On Sat, Feb 28, 2026 at 7:52 PM Maulin Vasavada
<ma...@gmail.com> wrote:
>
> On second thought, if the suggested abstraction becomes closer to existing abstraction available, then Stefan's original suggestion of having Cloud provider specific implementations of existing abstraction make sense. We can have discussion on making HashiCorp's implementation available as part of Cassandra or not separately.
>
> On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com> wrote:
>>
>> Looks like a good addition to me! I agree we could first implement a generic solution followed by cloud provider specific implementations. However, we should make the VaultSslContextFactory abstract to leave it optional to allow someone to integrate with a potential inhouse legacy solution for a Vault. We should have a concrete implementation that does have HashiCorp name in it based on that abstraction. What do you guys think?
>>
>> One clarification question for Bharath- I know you mentioned that this is a generic Vault integration but are there any HashiCorp specific things at all? I've not done any integration with HashiCorp Vault but I feel there are a lot of nuances in that area and less unification - e.g. I am not sure if there is a S3 API like standard- that exists for object storage, to bring all "vaults/secrets-manager" under one umbrella.  Given that it would be better to have the above approach of abstraction for Vault and HashiCorp specific implementation.
>>
>> Thanks!
>> Maulin
>>
>> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com> wrote:
>>>
>>> Hi Stefan,
>>>
>>> Thank you for the feedback! The AWS IAM auth approach is a great idea, and I completely agree that it provides a stronger security posture for EC2-based deployments by eliminating credentials on the node.
>>>
>>> That said, the goal of this patch is to provide a generic, cloud-vendor-independent integration with HashiCorp Vault that works across AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is Vault's recommended auth method for machine-to-machine authentication in any infrastructure.
>>> I'd propose we use this patch as the foundation and add cloud-native auth methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as separate implementations or as additional auth strategies within the same factory. This way, we can deliver a generic solution while we build out cloud-specific enhancements.
>>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement if the community agrees this is the right direction.
>>>
>>> Regards,
>>> Bharath Kumar B
>>>
>>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org> wrote:
>>>>
>>>> I want to add that while the proposed patch might work, it would be
>>>> way better to integrate with this (1). The "problem" with the patch I
>>>> see is that instead of storing passwords in cassandra.yaml (or in
>>>> files we read from) we need yet another type of credential (vault role
>>>> id / secret id) we also need to store somewhere. So the credentials
>>>> are still around in some fashion. So instead of that, (1) enables you
>>>> to get Vault token from EC2 instances. So there are truly no
>>>> credentials stored on a Cassandra node which seems to be a way more
>>>> robust solution.
>>>>
>>>> Maybe it would be better to welcome this type of contribution while
>>>> proposing to "harden" this solution like proposed above? Or the patch
>>>> might go in as well?
>>>>
>>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>>>>
>>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>>>> <sm...@apache.org> wrote:
>>>> >
>>>> > There was a ticket created in (1) which wanted to make SSL context
>>>> > creation pluggable / to fetch credentials remotely. I mentioned in (1)
>>>> > that this is already possible to do as SSL context creation is
>>>> > pluggable since CASSANDRA-16666.
>>>> >
>>>> > The author of that ticket returned back saying that they used this
>>>> > extensibility we provide (yay!) and they created an integration with
>>>> > HashiCorp Vault (2).
>>>> >
>>>> > Looking at the patch, there are no additional libraries /
>>>> > dependencies, it just calls it via HTTP.
>>>> >
>>>> > I want to ask if we can add this to the Cassandra codebase. While it
>>>> > is a custom implementation and it is great that users integrate with
>>>> > it, I think it is equally important to have this baked in so more
>>>> > people can profit from this.
>>>> >
>>>> > We already integrate various location providers
>>>> > (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>>>> > Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>>>> > is already a precedent in this kind of contributions which integrate
>>>> > with external systems.
>>>> >
>>>> > Are people OK with this?
>>>> >
>>>> > Regards
>>>> >
>>>> > (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>>>> > (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Maulin Vasavada <ma...@gmail.com>]

On second thought, if the suggested abstraction becomes closer to existing
abstraction available, then Stefan's original suggestion of having Cloud
provider specific implementations of existing abstraction make sense. We
can have discussion on making HashiCorp's implementation available as part
of Cassandra or not separately.

On Fri, Feb 27, 2026 at 10:27 PM Maulin Vasavada <ma...@gmail.com>
wrote:

> Looks like a good addition to me! I agree we could first implement a
> generic solution followed by cloud provider specific implementations.
> However, we should make the VaultSslContextFactory abstract to leave it
> optional to allow someone to integrate with a potential inhouse legacy
> solution for a Vault. We should have a concrete implementation that does
> have HashiCorp name in it based on that abstraction. What do you guys think?
>
> One clarification question for Bharath- I know you mentioned that this is
> a generic Vault integration but are there any HashiCorp specific things at
> all? I've not done any integration with HashiCorp Vault but I feel there
> are a lot of nuances in that area and less unification - e.g. I am not sure
> if there is a S3 API like standard- that exists for object storage, to
> bring all "vaults/secrets-manager" under one umbrella.  Given that it would
> be better to have the above approach of abstraction for Vault and HashiCorp
> specific implementation.
>
> Thanks!
> Maulin
>
> On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <
> kumar.bharathb023@gmail.com> wrote:
>
>> Hi Stefan,
>>
>> Thank you for the feedback! The AWS IAM auth approach is a great idea,
>> and I completely agree that it provides a stronger security posture for
>> EC2-based deployments by eliminating credentials on the node.
>>
>> That said, the goal of this patch is to provide a generic,
>> cloud-vendor-independent integration with HashiCorp Vault that works across
>> AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is
>> Vault's recommended auth method for machine-to-machine authentication in
>> any infrastructure.
>> I'd propose we use this patch as the foundation and add cloud-native auth
>> methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as
>> separate implementations or as additional auth strategies within the same
>> factory. This way, we can deliver a generic solution while we build out
>> cloud-specific enhancements.
>> Happy to open a follow-up JIRA ticket to track the AWS IAM auth
>> enhancement if the community agrees this is the right direction.
>>
>> Regards,
>> Bharath Kumar B
>>
>> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org>
>> wrote:
>>
>>> I want to add that while the proposed patch might work, it would be
>>> way better to integrate with this (1). The "problem" with the patch I
>>> see is that instead of storing passwords in cassandra.yaml (or in
>>> files we read from) we need yet another type of credential (vault role
>>> id / secret id) we also need to store somewhere. So the credentials
>>> are still around in some fashion. So instead of that, (1) enables you
>>> to get Vault token from EC2 instances. So there are truly no
>>> credentials stored on a Cassandra node which seems to be a way more
>>> robust solution.
>>>
>>> Maybe it would be better to welcome this type of contribution while
>>> proposing to "harden" this solution like proposed above? Or the patch
>>> might go in as well?
>>>
>>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>>>
>>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>>> <sm...@apache.org> wrote:
>>> >
>>> > There was a ticket created in (1) which wanted to make SSL context
>>> > creation pluggable / to fetch credentials remotely. I mentioned in (1)
>>> > that this is already possible to do as SSL context creation is
>>> > pluggable since CASSANDRA-16666.
>>> >
>>> > The author of that ticket returned back saying that they used this
>>> > extensibility we provide (yay!) and they created an integration with
>>> > HashiCorp Vault (2).
>>> >
>>> > Looking at the patch, there are no additional libraries /
>>> > dependencies, it just calls it via HTTP.
>>> >
>>> > I want to ask if we can add this to the Cassandra codebase. While it
>>> > is a custom implementation and it is great that users integrate with
>>> > it, I think it is equally important to have this baked in so more
>>> > people can profit from this.
>>> >
>>> > We already integrate various location providers
>>> > (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>>> > Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>>> > is already a precedent in this kind of contributions which integrate
>>> > with external systems.
>>> >
>>> > Are people OK with this?
>>> >
>>> > Regards
>>> >
>>> > (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>>> > (2)
>>> https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>>>
>>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Maulin Vasavada <ma...@gmail.com>]

Looks like a good addition to me! I agree we could first implement a
generic solution followed by cloud provider specific implementations.
However, we should make the VaultSslContextFactory abstract to leave it
optional to allow someone to integrate with a potential inhouse legacy
solution for a Vault. We should have a concrete implementation that does
have HashiCorp name in it based on that abstraction. What do you guys think?

One clarification question for Bharath- I know you mentioned that this is a
generic Vault integration but are there any HashiCorp specific things at
all? I've not done any integration with HashiCorp Vault but I feel there
are a lot of nuances in that area and less unification - e.g. I am not sure
if there is a S3 API like standard- that exists for object storage, to
bring all "vaults/secrets-manager" under one umbrella.  Given that it would
be better to have the above approach of abstraction for Vault and HashiCorp
specific implementation.

Thanks!
Maulin

On Fri, Feb 27, 2026 at 11:57 AM kumar bharath <ku...@gmail.com>
wrote:

> Hi Stefan,
>
> Thank you for the feedback! The AWS IAM auth approach is a great idea, and
> I completely agree that it provides a stronger security posture for
> EC2-based deployments by eliminating credentials on the node.
>
> That said, the goal of this patch is to provide a generic,
> cloud-vendor-independent integration with HashiCorp Vault that works across
> AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is
> Vault's recommended auth method for machine-to-machine authentication in
> any infrastructure.
> I'd propose we use this patch as the foundation and add cloud-native auth
> methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as
> separate implementations or as additional auth strategies within the same
> factory. This way, we can deliver a generic solution while we build out
> cloud-specific enhancements.
> Happy to open a follow-up JIRA ticket to track the AWS IAM auth
> enhancement if the community agrees this is the right direction.
>
> Regards,
> Bharath Kumar B
>
> On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>> I want to add that while the proposed patch might work, it would be
>> way better to integrate with this (1). The "problem" with the patch I
>> see is that instead of storing passwords in cassandra.yaml (or in
>> files we read from) we need yet another type of credential (vault role
>> id / secret id) we also need to store somewhere. So the credentials
>> are still around in some fashion. So instead of that, (1) enables you
>> to get Vault token from EC2 instances. So there are truly no
>> credentials stored on a Cassandra node which seems to be a way more
>> robust solution.
>>
>> Maybe it would be better to welcome this type of contribution while
>> proposing to "harden" this solution like proposed above? Or the patch
>> might go in as well?
>>
>> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>>
>> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
>> <sm...@apache.org> wrote:
>> >
>> > There was a ticket created in (1) which wanted to make SSL context
>> > creation pluggable / to fetch credentials remotely. I mentioned in (1)
>> > that this is already possible to do as SSL context creation is
>> > pluggable since CASSANDRA-16666.
>> >
>> > The author of that ticket returned back saying that they used this
>> > extensibility we provide (yay!) and they created an integration with
>> > HashiCorp Vault (2).
>> >
>> > Looking at the patch, there are no additional libraries /
>> > dependencies, it just calls it via HTTP.
>> >
>> > I want to ask if we can add this to the Cassandra codebase. While it
>> > is a custom implementation and it is great that users integrate with
>> > it, I think it is equally important to have this baked in so more
>> > people can profit from this.
>> >
>> > We already integrate various location providers
>> > (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
>> > Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
>> > is already a precedent in this kind of contributions which integrate
>> > with external systems.
>> >
>> > Are people OK with this?
>> >
>> > Regards
>> >
>> > (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
>> > (2)
>> https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>>
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[kumar bharath <ku...@gmail.com>]

Hi Stefan,

Thank you for the feedback! The AWS IAM auth approach is a great idea, and
I completely agree that it provides a stronger security posture for
EC2-based deployments by eliminating credentials on the node.

That said, the goal of this patch is to provide a generic,
cloud-vendor-independent integration with HashiCorp Vault that works across
AWS, Azure, GCP, on-premises, and bare metal environments. AppRole is
Vault's recommended auth method for machine-to-machine authentication in
any infrastructure.
I'd propose we use this patch as the foundation and add cloud-native auth
methods (AWS IAM, Azure MSI, GCP IAM) as follow-on contributions—either as
separate implementations or as additional auth strategies within the same
factory. This way, we can deliver a generic solution while we build out
cloud-specific enhancements.
Happy to open a follow-up JIRA ticket to track the AWS IAM auth enhancement
if the community agrees this is the right direction.

Regards,
Bharath Kumar B

On Fri, Feb 27, 2026 at 1:22 PM Štefan Miklošovič <sm...@apache.org>
wrote:

> I want to add that while the proposed patch might work, it would be
> way better to integrate with this (1). The "problem" with the patch I
> see is that instead of storing passwords in cassandra.yaml (or in
> files we read from) we need yet another type of credential (vault role
> id / secret id) we also need to store somewhere. So the credentials
> are still around in some fashion. So instead of that, (1) enables you
> to get Vault token from EC2 instances. So there are truly no
> credentials stored on a Cassandra node which seems to be a way more
> robust solution.
>
> Maybe it would be better to welcome this type of contribution while
> proposing to "harden" this solution like proposed above? Or the patch
> might go in as well?
>
> (1) https://developer.hashicorp.com/vault/docs/auth/aws
>
> On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
> <sm...@apache.org> wrote:
> >
> > There was a ticket created in (1) which wanted to make SSL context
> > creation pluggable / to fetch credentials remotely. I mentioned in (1)
> > that this is already possible to do as SSL context creation is
> > pluggable since CASSANDRA-16666.
> >
> > The author of that ticket returned back saying that they used this
> > extensibility we provide (yay!) and they created an integration with
> > HashiCorp Vault (2).
> >
> > Looking at the patch, there are no additional libraries /
> > dependencies, it just calls it via HTTP.
> >
> > I want to ask if we can add this to the Cassandra codebase. While it
> > is a custom implementation and it is great that users integrate with
> > it, I think it is equally important to have this baked in so more
> > people can profit from this.
> >
> > We already integrate various location providers
> > (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> > Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
> > is already a precedent in this kind of contributions which integrate
> > with external systems.
> >
> > Are people OK with this?
> >
> > Regards
> >
> > (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> > (2)
> https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch
>

Re: [DISCUSS] HashiCorp Vault SSL Integration

[Štefan Miklošovič <sm...@apache.org>]

I want to add that while the proposed patch might work, it would be
way better to integrate with this (1). The "problem" with the patch I
see is that instead of storing passwords in cassandra.yaml (or in
files we read from) we need yet another type of credential (vault role
id / secret id) we also need to store somewhere. So the credentials
are still around in some fashion. So instead of that, (1) enables you
to get Vault token from EC2 instances. So there are truly no
credentials stored on a Cassandra node which seems to be a way more
robust solution.

Maybe it would be better to welcome this type of contribution while
proposing to "harden" this solution like proposed above? Or the patch
might go in as well?

(1) https://developer.hashicorp.com/vault/docs/auth/aws

On Fri, Feb 27, 2026 at 7:47 PM Štefan Miklošovič
<sm...@apache.org> wrote:
>
> There was a ticket created in (1) which wanted to make SSL context
> creation pluggable / to fetch credentials remotely. I mentioned in (1)
> that this is already possible to do as SSL context creation is
> pluggable since CASSANDRA-16666.
>
> The author of that ticket returned back saying that they used this
> extensibility we provide (yay!) and they created an integration with
> HashiCorp Vault (2).
>
> Looking at the patch, there are no additional libraries /
> dependencies, it just calls it via HTTP.
>
> I want to ask if we can add this to the Cassandra codebase. While it
> is a custom implementation and it is great that users integrate with
> it, I think it is equally important to have this baked in so more
> people can profit from this.
>
> We already integrate various location providers
> (AlibabaCloudLocationProvider, AzureCloudLocationProvider,
> Ec2LocationProvider, GoogleCloudLocationProvider and so on) so there
> is already a precedent in this kind of contributions which integrate
> with external systems.
>
> Are people OK with this?
>
> Regards
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-21153
> (2) https://issues.apache.org/jira/secure/attachment/13080996/CASSANDRA-21153-vault-sslcontextfactory.patch