Clojurians Log v2

i think the answer here is no, but: <https://docs.aws.amazon.com/cli/latest/reference/redshift/get-cluster-credentials.html> I saw cognitect.aws.credentials/auto-refreshing-credentials and wondered if there was anything I might reuse in there to have an atom containing up-to-date temporary credentials.

I wrote a little (future (while true (reset! credentials (fetch-credentials ...)) (Thread/sleep ...))) thing, but having retry, backoff, etc. managed by the lib would be nice, since some of the sauce is already in the client API.

yeah, for STS temporary creds, there needs to be a refresh, on some interval or maybe even a HTTP lib middleware, which would check against the expiration time (given some buffer to cover cock drift)

AWS Java libs encompass this via a refresh() method that the user is required to call on the background: https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentialsProvider.html#refresh--

haven’t really looked into what would be most suitable place for such in the aws-api

on the AWS Java libs: > Forces this credentials provider to refresh its credentials. For many implementations of credentials provider, this method may simply be a no-op, such as any credentials provider implementation that vends static/non-changing credentials. For other implementations that vend different credentials through out their lifetime, this method should force the credentials provider to refresh its credentials.

Thinking that in this way, they push the refresh responsibility to the clients

I’d kinda like to try the middleware approach

to check the creds expiration “on the way out”

just that one would have to know the type of the creds then

how do people deal with these expiring credentials elsewhere? 🙂

https://github.com/cognitect-labs/aws-api/blob/master/examples/assume_role_example.clj

@devn @viesti

whoa ❤️

damn, this has been thought out well :)

🙇

@ghadi nice, but this wouldn't really apply to the get-cluster-credentials call, right? it retrieves a DbPassword and DbUser, but maybe I'm missing something

oh those are redshift creds, not AWS creds

@ghadi yessir, which is why i assume it's not a covered case, but i wondered if there were enough versions of same floating around that something could be provided to handle autorefresh for me

you can steal the skeleton from credentials.clj

word, yeah, gonna take that as a "not in my AWS API" 😄

hum, the Redshift jdbc driver is able to fetch credentials when establishing a connection

if you provide a suitable jdbc url that tells the cluster id

it's simple to just fetch new credentials when making a connection

no need to cache

@viesti have a link to where you see that by any chance?

sure https://docs.aws.amazon.com/redshift/latest/mgmt/generating-iam-credentials-configure-jdbc-odbc.html

user name and groups to join and whether to create the user while connecting can be specified options in the jdbc url https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc-and-odbc-options-for-database-credentials.html

user creation and joining groups needs permissions that can be specified via policies attached to the role/user using the jdbc driver

one could call the redshift get-cluster-credentials api, but at least in our case, it's been easier to let the aws provided jdbc driver do so

although the driver seems to have a bug which prevents this working in a lambda (tried filing a support ticket but this never got fixed)

but in general, was thinking that redshift connections aren't probably made that often that credentials would need to be cached

@viesti wow, can't believe i missed that. thank you!

😄

I remember seeing autocreate=true and tossing it aside as something related to db or cluster creation