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
Can't use temp credentials returned from assume role if they have special characters #599
Comments
Experiencing the same issue |
I have opened a PR with a workaround for this issue, regenerating the credentials until we get ones with no special characters. In my experiments, it's even enough to only make sure that the secret access key does not start with a special character, this way we cause way less retries. |
Some of my team are encountering this as well. |
No one's taken a look at my PR, but we've been using it ever since and it works really well for us, so consider trying something similar |
From the CLI docs:
Given this last line, I'd lean towards the best solution for us being regenerating the credentials if a special character is detected |
That is exactly what I did in my (closed without any discussion or comment) PR here #613 which my team's has been using for quite a while now without any issues |
Thanks for the previous PR @AvivPeledTalon, and sorry we closed this with little communication. We're currently in active development in the next version of this action. That makes reviewing PRs for the current version tricky to review especially with the limited dev time we can commit to this project, since we're making a few big changes in the next version (converting the project to ts, and using js v3 instead of v2). If this feature is important to you, I would recommend sticking with your own solution for now, and look forward to our next major version |
** Note ** |
Describe the bug
My team moved our to using assume-role instead of const access keys recently, and since then we've been seeing a lot of SignatureDoesNotMatch errors.
Digging deeper into this issue, we discovered that the AWS_SECRET_ACCESS_KEY in all of the runs that failed contained a special character ('/'), and that it might cause this kind of issues (see https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html, aws/aws-cli#2665, aws/aws-cli#602)
Our temporary solution is to try and generate another set of credentials in case we get this kind of error (run configure-aws-credentials with assume role again) and hope for the best.
This reduces the chances for our workflows to fail because of this issue, but it still might happen.
Since this issue appears in the awscli troubleshooting guide, I'm guessing they're not going to change the client to support that, and won't stop issuing credentials with special characters.
My hope is that at least this action itself could identify special characters in the temporary credentials it gets and regenerate them if necessary
Expected Behavior
I expect to be able to use AWS after running configure-aws-credentials successfully.
Current Behavior
Statistically, running configure-aws-credentials with assume role succeeds, but the temp credentials have special characters in them which is known to cause issues.
Reproduction Steps
If you run this on 200 Windows instances (using matrix for example) you will see some of them failing due to Signature Mismatch.
If you check the credentials you got on the failed runs they will have special characters in them.
Possible Solution
Additional Information/Context
No response
The text was updated successfully, but these errors were encountered: