[Cyberduck-trac] [Cyberduck] #11649: Can't reorder new S3 session, some previously working S3 sessions are broken, may be related to aws-vault

Cyberduck trac at cyberduck.io
Fri Apr 16 01:47:44 UTC 2021


#11649: Can't reorder new S3 session, some previously working S3 sessions are
broken, may be related to aws-vault
------------------------+-------------------
    Reporter:  mjcsb    |      Owner:
        Type:  defect   |     Status:  new
    Priority:  normal   |  Milestone:
   Component:  core     |    Version:  7.8.5
    Severity:  blocker  |   Keywords:  S3
Architecture:           |   Platform:
------------------------+-------------------
 I haven't used this in a few months, just opened and tried to create a new
 S3 session, I know the access/secret key works, but it refuses to list.
 The error I'm getting is:

 Listing directory / failed.
 Access Denied. Please contact your web hosting service provider for
 assistance.

 I then tried an existing session, and I know one that worked before no
 longer works, despite no changes to the access key pair.

 I then tried to move the new session from the bottom of perhaps 50
 existing sessions up to the top, and I could not move the session, it kept
 reverting to the bottom. I tried moving to the middle, reverted to the
 bottom.

 I opened this ticket to report, and while I started to write it, I
 realized that the two affected sessions (new + existing) are both sessions
 where I have commented out the credentials in ~/.aws/credentials, and have
 added an mfa_serial= property in the ~/.aws/config. I am in the process of
 testing prior to switching to the use of the aws-vault method of securely
 storing the AWS credentials in the macOS keychain, so these credentials
 are no longer insecurely stored in plain text in the non-encrypted
 ~/.aws/credentials file. Please see more about this project here:
 https://github.com/99designs/aws-vault

 This method is used in the Terraform community to run Terraform code via
 the CLI with MFA auth using STS temp tokens, as a more secure method of
 using the CLI.

 I thought Cyberduck was saving and using the access/secret key for
 sessions in it's own database? Why ask for them if instead it is
 referencing the ~/.aws/* files - when if that's the case, you should just
 collect the profile to use to lookup the config and credentials file
 values?

 It seems like there is some hidden / non-documented behavior where the
 ~/.aws config files are referenced, despite the fact your UI asks me
 specifically for these values, implying there is no such link and you
 store the values internally and separately from the AWS CLI configuration.

 So, if I switch to using this tool, and it breaks what I thought was
 independent use of CyberDuck as an S3 browser, this would make CyberDuck
 useless to me, so I think this is a pretty severe bug.

 I think you either need to:
 A: Accept a secret/access key, store that internal to your app config, and
 do not reference the AWS CLI configuration information stored under
 ~/.aws/* - this is a separate tool, why would you depend on it in this
 use-case??

 B: As an alternative to A, allow the user to specify a profile, and by
 such a choice, this means you would lookup the information stored in the
 ~/.aws/* config used by AWS CLI, and you would NOT store the access/secret
 key in your own config, as that would be redundant.

 C: Better yet, figure out some way to work with aws-vault, as this seems
 to be an increasingly used tool in the infrastructure-as-code community
 with Terraform and AWS.

 What you have there now, is the worst of all options, in that I'm
 specifying the access/secret key pair to avoid changes I'm making to
 increase security on use of the AWS CLI, which I thought would be
 independent of a separate S3 browser tool, not a profile, yet you're still
 depending on this separate tool's config, even though you're double-
 collecting the same credential information.

 I'd bet if your engineers contacted this open source project, you could
 work together to find a way to use the same aws-vault additional keystone
 in the MacOS KeyChain to lookup the values by name, or use their method of
 using STS to create temp tokens, increasing your own security and
 compatibility.

 I really like your tool for S3 access! Please don't let my use of aws-
 vault to improve security in AWS CLI and/or Terraform and/or
 CloudFormation use via CLI commands break what SHOULD be a completely
 separate S3 browser tool.

 I don't know what you did with recent updates, but it seems multiple
 issues are now broken.

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


More information about the Cyberduck-trac mailing list