You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I stopped using Cyberduck a couple years ago as multi-account became increasingly common, and I moved to use of aws-vault to store credentials in the MacOS or Windows keychain or use AWS SSO (pre-control tower), neither of which worked with Cyberduck, making it increasingly difficult to use without keeping a duplicate set of credentials.
I decided to try it again today, and noticed the new credentials option to obtain credentials from ~/.aws/config, where I have a bunch of SSO based credentials setup for many accounts organized via AWS Control Tower. For the first account, I added the bookmark, specified the profile name (based on SSO), and then double-clicked to open - nothing.
I figured, just as with the command line, I needed to first run "aws sso login --profile $profile", which I did, then also confirmed on the same CLI I could see data using a simple command like "aws ec2 describe-regions --profile $profile", so when I went back into Cyberduck and then clicked on the bookmark, it worked. I was glad to see this appeared to make Cyberduck usable again for large-scale / enterprise-level AWS multi-account scenarios!
So, I then went in and setup a bunch of other bookmarks based on other SSO profiles. But when I next tried to double-click these profiles, they would all hang. I went into the CLI, confirmed the profile worked, then once at least one CLI command was run against the profile (note I was never prompted for another aws sso login command on the CLI once the first one was done) on the CLI, Cyberduck would then work against that profile. OK, this is not good, I may have dozens of accounts, so this is going to make this so inconvenient again, just like before, to where the cons outweigh the pros...
I Googled your docs and found a reference https://docs.cyberduck.io/protocols/s3/ where it indicates both the aws sso login and at least one command like aws sts get-caller-identity needs to be run to get the STS tokens you need into cache for use. So, at least with the current design, I see what's happening.
The problem is, this effectively makes Cyberduck difficult to use, so much so I'm unlikely to want to use it much still. So, I thought I'd suggest a couple of improvements which you could make to reduce developer friction on use.
When I setup the bookmark, using the "S3 (Credentials from AWS Command Line Interface)" type, you have the name of the profile in the ~/.aws/config file, which should be readable by your program, so you can look into that profile and detect that it's based on SSO. Why do I have to run the "aws sts get-caller-identity --profile $profile"? Why can't you run this for me, some exec method to run a shell command as the user?
Same as (1), if you detect that this is an SSO profile, if you try to run (1), and that fails with an error code indicating the user has not logged in yet, why can't you run the "aws sso login --profile $profile" command for me? This does interact with the browser, not sure if that complicates things, and if so this does only need to be run once, so it's less onerous, but if you can't run it, at least popping up a dialog box saying "Open a terminal and run 'aws sso login --profile $profile', then retry" or similar.
The problem is (1) when you have a large number of accounts. It makes this program less usable than it should/could be. running a couple of shell commands when you have every parameter of data needed to run them from the configuration you collect would seem to be trivial, but would result in significant ease-of-use improvements. If you can't do this, at least explain why, and use dialog boxes to indicate to the user what they must do, so we don't have to guess or search your documentation for why this doesn't "just work".
I stopped using Cyberduck a couple years ago as multi-account became increasingly common, and I moved to use of aws-vault to store credentials in the MacOS or Windows keychain or use AWS SSO (pre-control tower), neither of which worked with Cyberduck, making it increasingly difficult to use without keeping a duplicate set of credentials.
I decided to try it again today, and noticed the new credentials option to obtain credentials from ~/.aws/config, where I have a bunch of SSO based credentials setup for many accounts organized via AWS Control Tower. For the first account, I added the bookmark, specified the profile name (based on SSO), and then double-clicked to open - nothing.
I figured, just as with the command line, I needed to first run "aws sso login --profile $profile", which I did, then also confirmed on the same CLI I could see data using a simple command like "aws ec2 describe-regions --profile $profile", so when I went back into Cyberduck and then clicked on the bookmark, it worked. I was glad to see this appeared to make Cyberduck usable again for large-scale / enterprise-level AWS multi-account scenarios!
So, I then went in and setup a bunch of other bookmarks based on other SSO profiles. But when I next tried to double-click these profiles, they would all hang. I went into the CLI, confirmed the profile worked, then once at least one CLI command was run against the profile (note I was never prompted for another aws sso login command on the CLI once the first one was done) on the CLI, Cyberduck would then work against that profile. OK, this is not good, I may have dozens of accounts, so this is going to make this so inconvenient again, just like before, to where the cons outweigh the pros...
I Googled your docs and found a reference https://docs.cyberduck.io/protocols/s3/ where it indicates both the aws sso login and at least one command like aws sts get-caller-identity needs to be run to get the STS tokens you need into cache for use. So, at least with the current design, I see what's happening.
The problem is, this effectively makes Cyberduck difficult to use, so much so I'm unlikely to want to use it much still. So, I thought I'd suggest a couple of improvements which you could make to reduce developer friction on use.
The problem is (1) when you have a large number of accounts. It makes this program less usable than it should/could be. running a couple of shell commands when you have every parameter of data needed to run them from the configuration you collect would seem to be trivial, but would result in significant ease-of-use improvements. If you can't do this, at least explain why, and use dialog boxes to indicate to the user what they must do, so we don't have to guess or search your documentation for why this doesn't "just work".