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