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