Nick et al,
Please help provide a sanity check on this enhancement. I looked through the forum and don't see something similar. My apologies if it is there.
First -- is anybody asking for this and will it become a standard?
Background Reauest
Enhance S3 authentication to include SSO temporary tokens per the AWS zero-trust model that can automatically refresh themselves.
What AWS did was to create software called "Identity Center" which was renamed from the SSO name. It "competes" with Microsoft AD and Okta. AWS best practice is to only use short term credentials. This becomes fun in an untrusted network like my Mac at home. To "solve" this they need to prove I am who I am. As such I log in to the identity center with IC/PW and as recommended a MFA token (Authy, Google hardware etc). If I pass the anuthentication I am ok. At least I passed MFA and know the UC/PW. The refresh only works while I have the access portal open and that is also limited to a relatively short term possibly 12-36 hours. So at a minimum if a nefarious actor gets my Mac they won't be able to access the system without my Authy key which is also protected by a password.
The challenge -- since this is relatively new not many packages support it.
Is this just an AWS bad idea?
As with many corporate ideas many don't make it. I think I am seeing some traction but then ....
The AWS CLI is integrated with this. I can use that to do a CLI "sync" but this doesn't have the advantages of your program, and for that matter, your support.
Next would be to integrate your FUSE mount but I don't think that will work with the refreshing tokens.
Request thoughts
Is the AWS solution gaining traction from your perspective?
The current industry methodology seems to be moving to a zero trust model which makes sense to me. That said, it will be fun to see how the industry responds to the zero-trust model.
I started down this path but got stuck with getSessionToken requiring a permanent access key. AWS strongly discourages permanent keys. Since AWS has much more experience than I do at securing their platform I try to stay with published best practices. In reality, the risks of personally doing something stupid is high.
Zero trust model
Always assume the hacker has gotten access to your account and your computer. Have you ever walked away from your computer for a few minutes and left it unlocked? What privileged information could the hacker gain if they accessed my computer? Could they get damaging financial information, damage ones reputation or possibly create a huge AWS bill that someone else pays for?
To that end, the Identity Center model is cool. In order to get a temporary token, the user must log into the Identity Center portal. Once the portal is open the user can see available "permissions". The user can create a key based on the desired available permission that will automatically refresh until the session timeout has been reached or terminated by the user. To get this far the user will need to supply:
My usercode
My password
The code from a pre-configured MFA
This is a bit more secure then just a pre-configured MFA.
Now is this a "practical advantage"? Well, yes, or maybe .
The challenge for RClone
Since RCloone has may destination types they will probably not want to implement something specifically for AWS S3 especially since even AWS hasn't completely made that migration yet. But if there is an industry standard all are migrating towards it would be nice to know what this might ba and how RClone might migrate
.