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 >
