Cyberduck Mountain Duck CLI

Changes between Version 1 and Version 2 of Ticket #10620, comment 3


Ignore:
Timestamp:
Feb 17, 2019 10:00:17 PM (2 years ago)
Author:
vwalveranta
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10620, comment 3

    v1 v2  
    1414- `current_code_from_generator`: the current generated token from the Google Authenticator -compatible code generator.
    1515
    16 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 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..`").
     16Creating 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.
     17
     18While 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..`").