[FEATURE REQUEST] Support storing Fastly CLI credentials in 3rd party backends
AriESQ opened this issue · 2 comments
Is your feature request related to a problem? Please describe.
It is bad practice to keep credentials on disk.
Describe the solution you'd like
I would like to see Fastly CLI support 3rd party secret backends. See for example Terraform Credential Helper, Git Credential Manager, AWS Vault, etc.
As well as the fact that all the platforms offer a credential manager these days.
- https://developer.apple.com/documentation/security/keychain_services/keychain_items/using_the_keychain_to_manage_user_secrets
- https://www.scriptinglibrary.com/languages/powershell/how-to-manage-secrets-and-passwords-with-credentialmanager-and-powershell/
- https://docs.kernel.org/security/keys/core.html
- https://github.com/99designs/aws-vault#vaulting-backends
- Password Managers (LastPass, KeepPass, 1Password, etc.)
Further I would like to see the starter documentation push users towards using a secure method. Perhaps allowing advanced users to use a derivation of an SSH key. Note that other infrastructure companies are moving towards requiring 2FA of their users (Github, PyPi).
Describe alternatives you've considered
I believe the documentation should be updated regardless. Pointing out users to where the token is stored, and what the dangers of storing it on disk are. Maybe there should be a check on what permissions the token has. Similar to how ssh-agent warns if a private SSH key has too open permissions.
Alternatives available are to inject the token at run-time as a secret. Perhaps the documentation should walk user's through some easy mode examples of that.
Additional context
I no longer work with Fastly. This is an observation from a previous engagement. Thank you, good luck.
Thanks @AriESQ for opening this issue. I've created an internal ticket to track and discuss this 👍🏻
An update: the CLI now offers the option of using OAuth/OIDC against manage.fastly.com for authentication. This still results in storing tokens in the config.toml file, but they are short-lived (the 'refresh' token currently has a maximum lifetime of 12 hours) and require reauthentication when they expire. That reauthentication can make use of 2FA in the Fastly Control Panel, or can even leverage a customer's third-party IdP if they've set that up using the 'Fastly SSO' product.