[Github #488] key rotation & UI updates

[khaliqgant]

Resolves #488
Resolves #996
Resolves #953

• Adds a button to allow a public key to be rotated on cloud only
  
• Adds a button to allow a private key to be rotated on cloud only
  
• Adds a dynamic loading of environments to allow for arbitrary environments. Note that there is no way at the moment to add environments besides direct database editing but this is a big step in that direction
• Allows environment variables to override secret and public keys on non cloud environments. Any environment variable with NANGO_SECRET_KEY_${env} and NANGO_PUBLIC_KEY_${env} can be used to override existing environments. This allows open source environments to have n number of environments

[bastienbeurier]

@khaliqgant rotating a key inadvertently would effectively create an outage for customers. Is there some confirmation prompt that makes it clear?

Also, I'm wondering what would be the rotation process for a customer with live connections because there would necessarily be a lag between the rotation and deploying the new public/private keys.

[khaliqgant]

@khaliqgant rotating a key inadvertently would effectively create an outage for customers. Is there some confirmation prompt that makes it clear?

Also, I'm wondering what would be the rotation process for a customer with live connections because there would necessarily be a lag between the rotation and deploying the new public/private keys.

1. Yeah there is a confirmation modal alerting the user that the old key will be invalidated.
2. With the current implementation it will be invalidated immediately. For secret key we could add some quick logic that the old key stays in the cache until the next deployment. For public key I don’t see anything quick. If we wanted something more complex we could add in an expiring window for the invalidating keys. delete_at column in the database and node cron that checks it

[bastienbeurier]

@khaliqgant rotating a key inadvertently would effectively create an outage for customers. Is there some confirmation prompt that makes it clear?
Also, I'm wondering what would be the rotation process for a customer with live connections because there would necessarily be a lag between the rotation and deploying the new public/private keys.

1. Yeah there is a confirmation modal alerting the user that the old key will be invalidated.
2. With the current implementation it will be invalidated immediately. For secret key we could add some quick logic that the old key stays in the cache until the next deployment. For public key I don’t see anything quick. If we wanted something more complex we could add in an expiring window for the invalidating keys. delete_at column in the database and node cron that checks it

Got it. We need to find a well-thought-out experience for people to rotate keys, without risking to shoot themselves in the foot.

The secret key will likely be stored in an env variable, and the public key could be stored in code.

Maybe a decent way would be to separate the new key generation and activation. So:

1. You generate a new key, but the old one still shows and is active
2. You activate the new key, and the old one disappears

In the future, the activation of the new key (specifically the backend) could happen programmatically so that it's perfectly timed with the rollout.

What do you think?

[khaliqgant]

@bastienbeurier yeah I like the activation concept - it is more explicit and also technically easier.

You generate a new key, but the old one still shows and is active

we’ll have to show the user the new key so they can copy it and prepare to activate it when ready right? Maybe show them the new key upon confirmation of creation? What would the UI look like when a new key is pending activation?

[bastienbeurier]

@bastienbeurier yeah I like the activation concept - it is more explicit and also technically easier.

You generate a new key, but the old one still shows and is active

we’ll have to show the user the new key so they can copy it and prepare to activate it when ready right? Maybe show them the new key upon confirmation of creation? What would the UI look like when a new key is pending activation?

Yeah exactly. Let me take a stab at some basic UX flow and I'll follow up.

[bastienbeurier]

@khaliqgant here's a proposed UX. The wireframes are on Figma.

Warning prompts could be:

Activate the new public key?
Make sure your code uses the new public key before activating. All authorization attempts with the previous public key will fail when the new key is activated.

Activate the new secret key?
Make sure your code uses the new secret key before activating. All requests made with the previous secret key will fail when the new key is activated.

Generate an HMAC key?
Make sure your code uses this HMAC key before activating. All authorization attempts without this HMAC key will fail after activation. Once enabled, HMAC verification cannot be disabled.

Activate the new HMAC key?
Make sure your code uses the new HMAC key before activating. All authorization attempts with the previous HMAC key will fail when the key is activated.