Fork me on GitHub
#aws
<
2019-02-28
>
devn01:02:15

i think the answer here is no, but: 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.

devn01:02:33

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.

viesti11:02:14

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)

viesti11:02:16

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

viesti11:02:46

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

viesti11:02:22

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.

viesti11:02:57

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

viesti11:02:18

I’d kinda like to try the middleware approach

viesti11:02:34

to check the creds expiration “on the way out”

viesti11:02:46

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

viesti11:02:17

how do people deal with these expiring credentials elsewhere? 🙂

viesti14:02:07

whoa ❤️

viesti14:02:30

damn, this has been thought out well :)

devn15:02:44

@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

ghadi15:02:30

oh those are redshift creds, not AWS creds

devn15:02:02

@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

ghadi15:02:26

you can steal the skeleton from credentials.clj

devn15:02:21

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

viesti15:02:52

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

viesti15:02:35

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

viesti15:02:49

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

viesti16:02:08

no need to cache

devn16:02:03

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

viesti16:02:29

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

viesti16:02:16

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

viesti16:02:58

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

viesti16:02:36

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)

viesti16:02:14

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

devn17:02:48

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

devn17:02:06

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