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