[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