You don't have to always use a specific user's AWS credentials to talk to AWS services. Instead, you can use temporary credentials. These come in a couple varieties. I've found the ones made available as part of EC2 IAM roles to be the most useful.
I have code to extract the credentials and security token for a given role from the metadata page that's available to EC2 instances. Because they're temporary, however, they do expire, and the obvious way to implement them allows for a race condition where a request to retrieve a new token happens after a request to a service with an expired token. The correct implementation requires that AWSCredentials gain get_temporary_secret_key and get_temporary_security_token methods that return Deferreds that fire after a refresh request has completed. This will require that callers use maybeDeferred.
It'll be a big change but it makes deploying code to EC2 instances much easier.
Where would this be? It's typically possible to avoid forcing maybeDeferred on users by internally handling the synchronous case with succeed and/or fail.
You don't have to always use a specific user's AWS credentials to talk to AWS services. Instead, you can use temporary credentials. These come in a couple varieties. I've found the ones made available as part of EC2 IAM roles to be the most useful.
I have code to extract the credentials and security token for a given role from the metadata page that's available to EC2 instances. Because they're temporary, however, they do expire, and the obvious way to implement them allows for a race condition where a request to retrieve a new token happens after a request to a service with an expired token. The correct implementation requires that
AWSCredentials
gainget_temporary_secret_key
andget_temporary_security_token
methods that return Deferreds that fire after a refresh request has completed. This will require that callers usemaybeDeferred
.It'll be a big change but it makes deploying code to EC2 instances much easier.