Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd: Allow SYSTEM_SECRET key rotation #73
Key rotation is tricky because we either need a table lock for JWK or an overlord. Having an overlord who is attached to rethinkdb might be the smartest thing to do. There should never be more than one overlord running (how to ensure this? table row? ttl?).
The system secret key rotation definitely needs an overlord. Key exchange could done through HTTP:
Alternatively the new secret could be encrypted with the old key and stored in the database. Everyone who has the old key, can read the new one as well. This would save the trouble of instance discovery as all instances are connected to rethinkdb anyways.
Using policies and IP ranges, access to the endpoint could be allowed to trusted addresses only.
On system key rotation, all JWKs must be re-encrypted using the new key. All tokens become invalid when the key changes which is why sysem key ttl must be larger than token ttl. This way we can be sure that all instances can validate tokens using either the old or the new key
For standard, regular key rotation that are meant to prevent key abuse, I would recommend a period of time where the old and new keys could be used. Basically the maximum expiry period for anything that would've been encrypted or signed with the old key.
If an existing key has been compromised, it should be replaced instantly and anything encrypted with the old key should be considered unsafe anyway and discarded. Locking during the replacement process would be nice, but ultimately there is going to be failing messages at some point if you're not respecting the previous keys anyway.