Registry sync should not delete profiles when failing to sync

[Nevon]

Currently the way that the sync works is that it deletes all the content of the aws config that was created by granted, and then it fetches the new configuration and writes it back into the config file. If there is any error syncing a registry, all the other profiles are added into the config file.

I encountered this behavior the other day when I couldn't find any of the profiles I expected. The reason was that at the beginning of the workday I forgot to connect to the company VPN, which means that the first time I used assume it tried to sync my profiles but couldn't reach the remote repository and thus deleted most of my profiles from my config. I didn't notice this until later when I was very confused.

My suggestion would be that the configuration should have some kind of marker that shows which registry a profile was synced from. If syncing from a particular registry fails, print an error but don't delete that section.

[Eddie023]

Hi @Nevon, thank you for raising this issue. Currently you can use --prefix-all-profile flag with granted registry add to add your registry name as prefix to show which registry a profile was synced from.

On the registry sync failure case, removing the whole section on error was so that user will have visibility if there is some issues with the latest remote registry sync and can quickly update it. But in your case it was caused on the user end which is a bit of a problem. I will have a look on how we can make this experience better. Thanks again for raising this!

[webframp]

Just hit this myself:

[i] Syncing Profile Registries
[!] Sync failed for registry o11n
[Γ£ö] Completed syncing Profile Registries

[Γ£ÿ] Granted couldn't find any AWS profiles in your config file or your credentials file
[i] You can add profiles to your AWS config by following our guide:
[i] https://docs.commonfate.io/granted/getting-started#set-up-your-aws-profile-file

I had valid config of course, remote git repo is unreachable during sync (with no way to skip sync when running assume) so sync fails and config is deleted

[sosheskaz]

"Automatically zero the configs I use for production access" is not an acceptable failure mode for something that runs automatically. It creates a situation where, if there is an SCM issue — whether client-side connectivity, configuration, or Github is down, users cannot access their AWS configs.

If you understand granted and granted registries well, there are generally workarounds, but the typical user should not need to be aware of them.

[chrnorm]

Fixed in #569