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
Read session token credentials from AWS CLI configuration file #10620
Comments
Not sure if I am correct but I assume we support this Connecting using AssumeRole from AWS Security Token Service (STS). |
Yes, I believe STS token feature is available for assuming roles i.e., to create a role session. However, there is no facility in Cyberduck at the moment to enter a baseprofile MFA session token. A baseprofile session is created like so:
Creating an MFA session as described above is basically analogous to entering an MFA code when logging in to AWS console, except that the awscli command spits out the MFA session credentials that with the console the web browser automatically caches. On CLI one has to either refer to the MFA profile with While a role can be used to bestow an IAM user additional privileges by assuming one, the baseprofile MFA can be used to block access to the IAM user altogether unless the user is in an active MFA session. In our enforcement policy, we allow a user (who has this policy) to configure their virtual MFA device, update their password, and create a new MFA session.. and nothing else. Once they have started an MFA session, then they have their regularly assigned privileges for the lasting of the session. During this time they can also assume roles, thus entering into a role session. Both the baseprofile MFA sessions and the role sessions create a wholly new set of credentials (i.e. separate from the baseprofile/source profile the session was created for): a new |
N.B.: If you implement this feature, you might find my |
One more thing :-) How are the baseprofile MFA sessions actually applicable to Cyberduck? Basically, if you have a set of AWS credentials, an The process would then be like this:
|
Can you confirm that you can successfully connect if you
Credentials should be read from the base profile configuration including the session token and the connection should succeed. |
Hello, Confirmed! This form of implementation is a great approach as this way the session credentials don't need to be coped into the connection profile every time. Well done! I would augment the documentation at https://trac.cyberduck.io/wiki/help/en/howto/s3#ConnectingusingAssumeRolefromAWSSecurityTokenServiceSTS |
Updated documentation available in Connecting using credentials in ~/.aws/credentials with additional profile in 10ba53f. |
👍 Thanks for the reference! :-) One typo fix: "...by third parties to facility managing credentials" -> "...by third parties to facilitate managing credentials". |
Replying to [comment:10 vwalveranta]:
Thanks! |
Ticket retargeted after milestone deleted |
When MFA is required/enforced in order to use for a given profile, it cannot be used with Cyberduck currently because Cyberduck doesn't allow the entry of the session token along with the standard AWS credentials. This is separate from the deletion token that can be set on S3 buckets, and when configured and enforced, it doesn't allow any access with given access key ID / secret access key unless a user is in MFA session (and so that the session token is also provided). When an MFA session is initialized, AWS provides a new access key ID and a new secret access key (they are separate from the credentials of the profile the MFA session was started for) in addition to the session token. These credentials are only valid for the validity period of the session.
This is supported, for example, by Cloudberry Explorer. I have created a set of scripts to manage the MFA sessions on the command line as my employer is moving to MFA enforcement also on the command line (with the enforcement enabled any tool that utilizes the access keys won't work unless it allows also the entry of the session token). The utility scripts and their documentation can be found at the following URL: https://github.com/vwal/awscli-mfa
The text was updated successfully, but these errors were encountered: