Skip to content
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

Closed
cyberduck opened this issue Feb 16, 2019 · 10 comments
Closed

Read session token credentials from AWS CLI configuration file #10620

cyberduck opened this issue Feb 16, 2019 · 10 comments
Assignees
Labels
feature fixed s3 AWS S3 Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

9a2dd02 created the issue

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

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Not sure if I am correct but I assume we support this Connecting using AssumeRole from AWS Security Token Service (STS).

@cyberduck
Copy link
Collaborator Author

9a2dd02 commented

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:

aws --profile "some_baseprofile" sts get-session-token --serial-number "mfa_arn_associated_with_the_baseprofile" --duration "3600" --token-code "current_code_from_generator" --output "json"
  • some_baseprofile: refers to the label name of a profile in ~/.aws/credentials or in ~/.aws/config
  • mfa_arn_associated_with_the_baseprofile: refers to the virtual MFA attached to the profile; this is the same vMFA that can be attached to the profile via the web console.
  • duration: can be enforced by the MFA enforcement policy (see example in my repo). Otherwise, it's the AWS default.
  • current_code_from_generator: the current generated token from the Google Authenticator -compatible code generator.

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 AWS_PROFILE evvar, or export the session credentials to the environment. With client apps like Cloudberry Explorer or Cyberduck, those MFA session credentials need to be entered into the connection profile.

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 aws_access_key_id, aws_secret_access_key, and aws_session_token. Cyberduck currently provides a way to enter the session token to assume a session, but not to use a baseprofile MFA. I'd recommend just adding an additional field ("Session Token") into the connection profile window for the S3 connections. If the field has content, then inject it into the request as aws_session_token. The credentials for MFA and non-MFA are of the same format except for the MFA sessions the session token is present (and the access key id begins "ASIA.." instead of "AKIA..").

@cyberduck
Copy link
Collaborator Author

9a2dd02 commented

N.B.: If you implement this feature, you might find my awscli-mfa.sh utility script useful for creating sessions to test with as the awscli API commands for creating and managing sessions are rather cumbersome. For more info see my repo at https://github.com/vwal/awscli-mfa

@cyberduck
Copy link
Collaborator Author

9a2dd02 commented

One more thing :-)

How are the baseprofile MFA sessions actually applicable to Cyberduck? Basically, if you have a set of AWS credentials, an aws_access_key_id, and aws_secret_access_key, but the MFA is set to be required for that IAM user, those credentials are no good for anything (such as for accessing the S3 buckets the user has privileges for) unless they provide the MFA session credentials instead of the corresponding baseprofile credentials.

The process would then be like this:

  1. In the aws CLI, the user starts an MFA session for their IAM account. AWS provides a new aws_access_key_id, aws_secret_access_key, and aws_session_token. My awscli-mfa.sh script can make this less painful.
  2. The user opens a client (currently Cloudberry Explorer or, hopefully, Cyberduck in the future :-) and enters the session credentials (including the aws_session_token) into the connection profile.
  3. The user connects normally to the S3 buckets their IAM account has the privileges for.
  4. Once the session ends, the access ends (and the user has to create a new MFA session in the CLI and update the session credentials in the connection profile to reconnect).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

9a2dd02 commented

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
under the subsection: "Read credentials from ~/.aws/credentials" to point out that if an AWS MFA session credentials (not only a role session credentials) are persisted in ~/.aws/credentials, that MFA or role session profile can be referred to directly, e.g. myprofile-mfasession instead of myprofile (the -mfasession and -rolessession postfixes are what my awscli-mfa.sh script, mentioned above, persists the MFA sessions and MFA-enabled role session credentials as, but users can, of course, name the MFA session profiles whichever way they like if they acquire the MFA/role session manually with awscli sts get-session-token command instead of using my utility script).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Updated documentation available in Connecting using credentials in ~/.aws/credentials with additional profile in 10ba53f.

@cyberduck
Copy link
Collaborator Author

9a2dd02 commented

👍

Thanks for the reference! :-)

One typo fix: "...by third parties to facility managing credentials" -> "...by third parties to facilitate managing credentials".

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:10 vwalveranta]:

👍

Thanks for the reference! :-)

One typo fix: "...by third parties to facility managing credentials" -> "...by third parties to facilitate managing credentials".

Thanks!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Ticket retargeted after milestone deleted

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature fixed s3 AWS S3 Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants