-
-
Notifications
You must be signed in to change notification settings - Fork 301
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
Missing session token when making the AssumeRoleRequest to obtain the cross account credentials from STS #10432
Comments
Can you confirm you have configured the bookmark using |
I can confirm I've tried to use both 'profile testrole' and 'testrole' and both give the same result. (with the credentials file also reflecting the same. |
Please enable debug logging and post the output in the |
Logs here, with the account number and bucket name redacted for security.
|
We try to obtain a new session token from AWS STS using the credentials in the AWS CLI profile named |
If I'm reading this right, you suggest we remove the profile DPMProdMaster-RO and the role_arn from the credentials file? Using no role in the credentials file and specifying default in the cyerduck profile config - I get listing directory denied (which is expected). |
Cross account/role based access should work. Not sure if I can follow but I want to clarify what we attempt in the different configuration deployment scenarios:
|
Ok, so this is how we are setup to work:
So we need a profile which will verify the existing session token and credentials in the aws credentials file, and allow us to use a cross account role with them. |
Thanks for your clarifications and patience with me ;) From my understanding now the bug is, that we do not include the session token when making the |
Yes I agree with that bug/conclusion summary. Thanks for waiting out for the full details/results! |
Please revoke the access key `` exposed in the log output. |
Access key revoked in log (woops, missed that one) I've added the DPMProdMaster-RO profile back into the credentials file with the role_arn specified, and source_profile as default, and everything is looking good! Thanks for the quick turnaround! |
Milestone renamed |
Since 6.7.0 there has been a functionality to use temporary credentials (session keys) for accessing S3.
I've downloaded the correct STS S3 profile and filled out the bookmark correctly.
I use a in house saml script to authenticate me and then create me an access key, secret key and session key, which are automatically put in the
.aws/credentials
file.If I use these credentials with the aws cli (for example
aws --profile test s3 ls
) it works without any issues.If I try to use Cyberduck however (specifying the same profile name) I get the following message:
Cannot read bucket versioning status
The profile in question has full S3 access, and so the message of cannot read bucket versioning status is wrong.
The one thing I am questioning is - we use a AWS account to authenticate and then we assume cross account roles to access the other accounts/services. The profile (which is a role on a child account) works fine using the CLI. Is it possible that Cyberduck is ignoring the role and just trying to login to the authentication AWS account?
Credentials file looks like the following:
Log Drawer:
This is currently stopping our ability to use the product for its intended purpose.
Any ideas?
The text was updated successfully, but these errors were encountered: