I have an AWS account with full access to DynamoDB.

I am writing an application that uses DynamoDB. I would like to test this application backed by the real DynamoDB (and not any local compatible/mock solution). However, the test application is not as secure a real production-ready application, and there is a real risk that during my tests an attacker may break into the test machine. If my real AWS credentials (needed to write to DynamoDB) are on that machine, they may be stolen and the attacker can basically do anything that I can do on DynamoDB - e.g., create expensive VMs in my account next week and mine for bitcoin.

So I'm looking for an alternative to saving my real AWS credentials (access key id and secret access key) on the test machine.

I read about Amazon's signature algorithm v4, and it turns out that its signature process is actually two-staged: First a "signing key" is calculated from the full credentials and this signing key works only for a single day on a single service - and then this "signing key" is used to sign the individual messages. This suggests that I could calculate the signing key on a secure machine and send it to the test machine - and the test machine will only do the second stage of the signature algorithm, and will only be able to use DynamoDB and only for a single day.

If I could do this, this would solve my problem, but the problem is that I couldn't figure out how I can tell boto3 to only do the second stage of the signing. It seems it always takes the full credentials aws_access_key_id and aws_secret_access_key - and does both stages of the signature. Is there a way to configure it to only do the second stage?

Alternatively, is there a different way in AWS or IAM or something, where someone like me that has credentials can use them to create temporary keys that can be used only for a short amount of time and/or only one specific service?

CodePudding user response：

create temporary keys that can be used only for a short amount of time and/or only one specific service

Yes, that's why AWS STS service exists. Specifically you can use GetSessionToken which:

Returns a set of temporary credentials for an AWS account or IAM user. The credentials consist of an access key ID, a secret access key, and a security token.

You can also create IAM roles, and used STS's AssumeRole for the same thing. Actually using IAM roles for instances is the most preferred way to give temporary permissions for the applications on EC2 instances. This way you don't have to use your own credentials at all.