-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws rds generate-db-auth-token generating invalid token when using .aws/credentials to authenticate #8234
Comments
Hi @scott-vandevoorde - thanks for reaching out and for well-detailed post. I followed steps to reproduce the issue but was unable to and I'd like verify a couple things:
If the issue persists, could you share full debug logs from Hope that helps, |
Hi @aBurmeseDev , thanks for looking into this issue! I think the main difference in our setups is I'm connecting to an IAM enabled RDS proxy. My RDS instance doesn't have IAM configured as the proxy handles it. Here's more detail around my setup. Our instances are complex, so I stood up a slimmed down stack and I was able to reproduce with this configuration:
------ testing the newly provisioned setup ------ We have an ec2 bastion running in the VPC. When I run the following. it can connect to the RDS proxy via IAM token:
Tokens generated on my local workbench via the same commands don't work. once I set the following environment variables, aws rds generate-db-auth-token starts to generate working tokens
Note: Adhoc3BastionStack-BastionHostRole-JDL6Y8KJ69VB is the role on the working bastion instance. My stored credentials have the following permissions, so it should be an issue with privilege.
I checked ~/.aws/credentials to see if anything was out of place. no dangling aws_session_token =. that would have been a great catch though.
then I called |
Glad to hear that it's working as expected now after running |
thanks for the detail! |
|
Describe the bug
When using credentials files (.aws/credentials & .aws/config) to authenticate with aws,
aws rds generate-db-auth-token
generates an invalid token.The invalid token is missing the field X-Amz-Security-Token
If I set environment variables AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, the token is generated successfully and is usable.
Expected Behavior
I expect the cli to generate a working token
Current Behavior
an invalid token is generated. The db says
password authentication failed for user "rdsproxyuser"
Reproduction Steps
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
aws configure
aws s3 ls
and ensure it connects okaws rds generate-db-auth-token --hostname adhoc3-amber-engine.proxy-cfds9ixmayu4.us-east-1.rds.amazonaws.com --port 5432 --region us-east-1 --username rdsproxyuser
(replace rds host name, and user name with the appropriate info){ "Action": [ "rds-db:connect" ], "Resource": "arn:aws:rds-db:us-east-1:*:dbuser:*/*", "Effect": "Allow" }
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::793478358630:user/scott" }, "Action": "sts:AssumeRole" }
export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" \ $(aws sts assume-role \ --role-arn arn:aws:iam::793478358630:role/Adhoc3BastionStack-BastionHostRole-JDL6Y8KJ69VB \ --role-session-name Adhoc3BastionSession \ --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \ --output text))
aws rds generate-db-auth-token --hostname adhoc3-amber-engine.proxy-cfds9ixmayu4.us-east-1.rds.amazonaws.com --port 5432 --region us-east-1 --username rdsproxyuser
Possible Solution
trace the cli workflows between the two authentication mechanisms and figure out why the X-Amz-Security-Token is not being included in the token. Also recommend generating an error message instead of a bad tokens.
Additional Information/Context
Two co-workers validated the same behavior. One on windows and one on mac.
CLI version used
aws-cli/2.10.3 Python/3.9.11 Windows/10 exe/AMD64 prompt/off
Environment details (OS name and version, etc.)
tested on windows 10
The text was updated successfully, but these errors were encountered: