[Cyberduck-trac] [Cyberduck] #10620: Add AWS session token field for S3 connections

Cyberduck trac at cyberduck.io
Sun Feb 17 20:52:02 UTC 2019


#10620: Add AWS session token field for S3 connections
-------------------------------+------------------------
 Reporter:  vwalveranta        |         Owner:  dkocher
     Type:  feature            |        Status:  new
 Priority:  normal             |     Milestone:
Component:  s3                 |       Version:  6.9.3
 Severity:  normal             |    Resolution:
 Keywords:  MFA session token  |  Architecture:
 Platform:                     |
-------------------------------+------------------------

Comment (by vwalveranta):

 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.
 - token-code: the current generated token from the Google Authenticator
 -compatible code generator.

 So, 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 adding just an additional
 field ("Session Token") into the connection profile window for S3
 connections. If the field has content, then inject that 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..").

--
Ticket URL: <https://trac.cyberduck.io/ticket/10620#comment:3>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows


More information about the Cyberduck-trac mailing list