If a join key is exposed it would allow anyone with the key to join machines into an omni instance. This could be abused by joining lots of machines into an Omni instance or if a cluster has machine classes set up potentially allow an unauthenticated machine to join a cluster.
Solution
We should have a way for users to rotate a join token in an Omni instance. This would probably be best to also handle machine "upgrades" by keeping both keys valid until all machines have switched to the new key.
Alternative Solutions
The current option is to deprovision omni and create a new instance with the same domain. It's not automated and very disruptive.
Notes
I don't think forcing users to delete all machines before rotating keys is a valid option because there's currently no way to export/import a cluster and that would be very disruptive for users.
Problem Description
If a join key is exposed it would allow anyone with the key to join machines into an omni instance. This could be abused by joining lots of machines into an Omni instance or if a cluster has machine classes set up potentially allow an unauthenticated machine to join a cluster.
Solution
We should have a way for users to rotate a join token in an Omni instance. This would probably be best to also handle machine "upgrades" by keeping both keys valid until all machines have switched to the new key.
Alternative Solutions
The current option is to deprovision omni and create a new instance with the same domain. It's not automated and very disruptive.
Notes
I don't think forcing users to delete all machines before rotating keys is a valid option because there's currently no way to export/import a cluster and that would be very disruptive for users.