Improve cache control

[iainelder]

It would be great if the flush help looked something like this:

$ aws-sso-cli flush --help
Usage: aws-sso flush

Flush AWS SSO/STS credentials from cache

Flags:
  -h, --help                               Show context-sensitive help.
  -b, --browser=STRING                     Path to browser to open URLs with ($AWS_SSO_BROWSER)
      --config="~/.aws-sso/config.yaml"    Config file ($AWS_SSO_CONFIG)
      --cache="~/.aws-sso/cache.json"      Cache file ($AWS_SSO_CACHE)
...

At least the location of the cache should be documented, if not also configurable using the AWS_SSO_CACHE environment variable.

It would have helped me avoid some confusion and investigation today.

I learned to set up aws-sso-cli to generate profiles for the stock AWS CLI. It's such a great feature, and I think it's going to really improve my experience of working with multiple accounts via SSO.

But the cache made the setup tricky.

The first time I ran the config-profiles command, I got an error about a duplicate profile name.

$ aws-sso-cli config-profiles --config=./.aws-sso/config.yaml --diff --lines
FATAL  /home/runner/work/aws-sso-cli/aws-sso-cli/cmd/aws-sso/main.go:202 main.main() Error running command: Duplicate profile name '111111111111:Admin' for:
abc: arn:aws:iam::111111111111:role/Admin
DefaultSSO: arn:aws:iam::111111111111:role/Admin 

This didn't make sense to me because my configuration didn't have DefaultSSO. It did initially, but then I renamed it to abc for the sake of naming the Firefox container.

I tried the flush command to clear the cache, but it didn't change the behavior of the config-profiles command.

$ aws-sso-cli flush --config=./.aws-sso/config.yaml --level=debug --lines --type=all
INFO   /home/runner/work/aws-sso-cli/aws-sso-cli/cmd/aws-sso/flush_cmd.go:75 main.flushSts() Deleted cached AWS STS credentials for abc   
INFO   /home/runner/work/aws-sso-cli/aws-sso-cli/cmd/aws-sso/flush_cmd.go:59 main.flushSso() Deleted cached AWS SSO Token for abc         

I looked in the help output of cache and flush and in the commands documentation but didn't see where the cache is located.

Finally I used opensnoop to discover the global user cache file at ~/.aws-sso/cache.json.

$ sudo opensnoop-bpfcc -n aws-sso-cli
...
64732  aws-sso-cli         9   0 /home/isme/.aws-sso
64732  aws-sso-cli        10   0 /home/isme/.aws-sso/cache.json

And then I confirmed that this cache file did contain a reference to DefaultSSO.

$ gron ~/.aws-sso/cache.json | grep -P 'DefaultSSO'
json.SSO.DefaultSSO = {};
json.SSO.DefaultSSO.History = [];
json.SSO.DefaultSSO.History[0] = "arn:aws:iam::111111111111:role/Admin";
json.SSO.DefaultSSO.History[1] = "arn:aws:iam::111111111111:role/ReadOnly";
json.SSO.DefaultSSO.LastUpdate = 1675784102;
...

So I just deleted the cache file.

rm ~/.aws-sso/cache.json

After that, the config-profiles command behaved as promised.

[synfinatic]

Honestly, this is a bug. Editing the config file to replace the SSO instance makes the cache invalid and it should have been regenerated. I'm glad that you were able to finally debug this, but honestly making people figure out they need to manually delete the cache file is a horrible UX and I'd rather just prevent it completely.

[iainelder]

Sure, that works too. Don't make me think about the cache! :-D Looking forward to the fix.

[iainelder]

I set up a new Identity Center instance in a new management account and created a new aws-sso config file.

The config for the abc and the def instances each defines a "billing" profile for a role in the management account.

When I run config-profiles for def, I get another "duplicate profile name" error.

$ aws-sso-cli config-profiles --force --level=info
INFO    Waiting for SSO authentication...            
INFO    Refreshing AWS SSO role cache for def, please wait... 
FATAL   Error running command: Duplicate profile name 'billing' for:
abc: arn:aws:iam::111111111111:role/ReadOnly
def: arn:aws:iam::222222222222:role/AWSAdministratorAccess

Again, I solve the error by deleting the global user cache file.

After that, I don't notice any problems when using the profiles via the stock CLI.

Is this another symptom of the same bug?