[ https://issues.apache.org/jira/browse/CASSANDRA-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937738#comment-17937738 ]
Michael Semb Wever commented on CASSANDRA-20416: ------------------------------------------------ Code and design _in general_ looks good. Topics that come to mind are: # if the server configures this, what happens to all the other drivers in other languages that don't have this client-side implementation available ? (python-driver is critical. but regardless this can seriously handicap a cluster's future capabilities) # what dependencies will this introduce ? # should we start thinking about how we package plugin implementations ? ** if in-tree and there's overlapping dependencies we need to be confident of future maintenance. an alternative is we make the impl a submodule and separate shaded jar, and look into separate classloaders for plugin impls (deserves a discussion). # should we start thinking about how we bundle our plugin interfaces ? (see dev@ thread: [https://lists.apache.org/thread/7x9wsn265mq5jd5q236y0nkjsw6ycbct] # i'd like to see benchmarking, not for so much throughput performance, but that to ensure availability and smooth operations over edge-cases, and to identify failure modes. (also falls into e2e/integration testing.) # getting the pdf written up into package markdown (if it is to come in-tree, it would need package change and code styling, ofc). vaguely related dev@ thread: [https://lists.apache.org/thread/trgyoo7vfdws1r0mthdtpzxdrc0nrsdk] I don't see anything in the plugin implementation itself that needs a CEP yet, IMHO. The questions (2) and (3) maybe, but depending on what's decided it might be a simple and obvious approach that's easy to incrementally discuss on… Taking (4) to the extreme, we should be able to configure configuration to use this implementation and push it through the entire CI pipeline (e.g. like our test variatations). I wouldn't want to permanently add this to the CI pipeline test types through. > AWS IAM-based client authenticator > ---------------------------------- > > Key: CASSANDRA-20416 > URL: https://issues.apache.org/jira/browse/CASSANDRA-20416 > Project: Apache Cassandra > Issue Type: New Feature > Components: Client/java-driver, Feature/Authorization > Reporter: Joel Shepherd > Priority: Normal > Attachments: STS-Based Authentication for Apache Cassandra.pdf > > > Enable Cassandra clients to authenticate to nodes using AWS IAM credentials, > with minimal required AWS dependencies. Use of IAM credentials allows secure > and centralized management of those credentials, and also enables use of > secure credential distribution mechanisms like EC2 instance roles (for > clients running on EC2). > I've drafted Java driver- and node-side plug-ins [1] [2] for early review. > This authenticator follows an approach initially developed by Heptio for > authenticating to Kubernetes clusters on AWS: > [https://github.com/kubernetes-sigs/aws-iam-authenticator] . The client uses > IAM credentials to create a pre-signed URL that invokes the GetCallerIdentity > API on the AWS Security Token Service (STS). The URL is passed to the node in > response to an authentication challenge. The node GETs the URL: if > successful, STS responds with the AWS account id, IAM principal name and IAM > principal ARN associated with the client's signing credentials. The principal > ARN is the client identity returned to Cassandra by the authenticator. The > attached PDF provides more detail on the approach. > I'm seeking feedback on the proposal and approach, feedback on the code, and > suggestions for preparing it for release (if folks believe it will be useful). > [1] Node authenticator plugin: > [https://github.com/jcshepherd/aws-sts-auth-cassandra-authenticator-plugin] > [2] Java driver plugin: > https://github.com/jcshepherd/aws-sts-auth-cassandra-java-driver-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org