[Cyberduck-trac] [Cyberduck] #8880: Authentication using AWS AssumeRole and GetSessionToken with AWS STS

Cyberduck trac at cyberduck.io
Wed Dec 13 23:49:58 UTC 2017


#8880: Authentication using AWS AssumeRole and GetSessionToken with AWS STS
----------------------------+-------------------------
 Reporter:  tigris          |         Owner:  dkocher
     Type:  feature         |        Status:  assigned
 Priority:  low             |     Milestone:
Component:  s3              |       Version:  4.7
 Severity:  normal          |    Resolution:
 Keywords:  s3 iam sts      |  Architecture:  Intel
 Platform:  Mac OS X 10.10  |
----------------------------+-------------------------
Changes (by mjcsb):

 * type:  enhancement => feature


Old description:

> I am using amazon AssumeRole function to assume a role that can access an
> S3 bucket. This means to connect to S3, it needs more than just SecretKey
> and AccessKey, it also need SecurityToken or SessionToken which is an
> extremely large string.
>
> If you set these 3 things in your environment, you can use tools like
> awscli etc from command line. I would like to use cyberduck instead as it
> can thread nicely. But unfortunately cyberduck only supports IAM users
> and not roles.
>
> It does support roles from an EC2 instance, so I think it should be very
> easy to support from my own OSX laptop? I was thinking of just running a
> local proxy for 169.254.169.254 to fake the fact I am not running on EC2,
> but it seemed like overkill.

New description:

 I am using amazon AssumeRole function to assume a role that can access an
 S3 bucket. This means to connect to S3, it needs more than just SecretKey
 and AccessKey, it also need SecurityToken or SessionToken which is an
 extremely large string.

 If you set these 3 things in your environment, you can use tools like
 awscli etc from command line. I would like to use cyberduck instead as it
 can thread nicely. But unfortunately cyberduck only supports IAM users and
 not roles.

 It does support roles from an EC2 instance, so I think it should be very
 easy to support from my own OSX laptop? I was thinking of just running a
 local proxy for 169.254.169.254 to fake the fact I am not running on EC2,
 but it seemed like overkill.

 I notice a few people are suggesting entry of the security token - but
 isn't that short-lived? Don't see how that's a stable configuration
 solution. When configuring AWS CLI for this, I'd have an entry for the
 master account, and then one entry for each assumed role, such as:

 [profile master]
 region = us-east-1
 output = json

 [profile security]
 role_arn = arn:aws:iam::999999999999:role/MyAccessRole
 source_profile = master
 region=eu-west-1
 output=json

 I think you need a way to collect and use this information, mainly the
 role_arn and reference to the source_profile.

--

Comment:

 I also need this.

 What would be AWESOME: instead of collecting the access_key_id and
 secret_key, you instead would collect the $AWS_DEFAULT_PROFILE or "--
 profile" as used in aws s3 CLI commands, so if we have configured awscli
 to use roles via lines in ~/.aws/config, this would simply work without
 having to double-enter the data in two locations.

 Happy if you provide an option to both store inside Cyberduck AND if not
 stored internally, attempt to lookup the profile inside ~/.aws/* too.

 But, AWS best practice for the last few years has been to use role
 assumption in any multi-account scenario, and they've been pushing multi-
 account at the enterprise level also for a few years, so I think you need
 to prioritize this - it seems to have been a request for years now.

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


More information about the Cyberduck-trac mailing list