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 >
