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 <[email protected]> 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č <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> > 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č <[email protected]> >> > > > 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 >> > > > <[email protected]> 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 >> > > >> <[email protected]> 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 >> > > >>> <[email protected]> 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č >> > > >>>> <[email protected]> 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č >> > > >>>>> <[email protected]> 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 >> > > >> > >> >
