[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