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 > > > > > > > >
