Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support to fetch shared secret from AWS Secrets Manager #6

Open
rgooch opened this issue Feb 20, 2020 · 0 comments
Open

Add support to fetch shared secret from AWS Secrets Manager #6

rgooch opened this issue Feb 20, 2020 · 0 comments

Comments

@rgooch
Copy link
Member

rgooch commented Feb 20, 2020

Note: this issue relates to the Web workflow, not the API/CLI workflow.

Cloud-Gate (can) have a shared secret which is used to sign JWTs, so that reloading the page is fast since you have a valid JWT. Support fetching this shared secret from AWS Secrets Manager.

Without a shared secret, Cloud-Gate generates a new secret at startup and uses a fixed cookie name for that secret. This leads to two different undesirable scenarios:

  1. In an environment with a single Cloud-Gate instance, every time it restarts the old cookies are invalidated and thus Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, which slows down the user experience.

  2. In an environment with multiple Cloud-Gate instances (required for HA), every time a user is bounced to a different instance (which can happen every time they reload the page), their cookie will be invalid (because each Cloud-Gate instance has a different signer key but they share the same cookie name), and again Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, slowing down the user experience (and dropping more cookies in the users web browser).

By using a shared secret stored remotely, the best user experience can be provided regardless of restarts, redeploys or switching between Cloud-Gate instances. However, it requires more infrastructure setup. Some simpler alternatives are discussed below:

(1) can be resolved by writing the generated secret to the file-system, so that a restart of Cloud-Gate does not effectively invalidate cookies. Redeploying instances will of course invalidate cookies if there is no external storage for the secret

(2) can be resolved by using a cookie name which is unique per instance (i.e. by folding in the hostname, IP address, MAC address)

Combining (1) and (2) yields a better experience, although redeploying instances will still result in new cookies and hence a slowdown each time users happen to hit a new instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant