mirror of
https://github.com/gravitational/teleport.git
synced 2026-09-19 01:58:44 +08:00
Tim Buckley
b6d7613992
* MWI: Ignore `user_login_state` for bots This change is part of a fix for gravitational/teleport#63920, where the Okta usermonitor will inadvertently create unneccessary ULS entries for bots when they are deleted. Normally, these ULS entries are sane, but if the bot is deleted and recreated too quickly, there's a race. Here's the sequence of events: 1. The user creates a bot (`tctl bots add` or similar) 2. The usermonitor watcher catches the OpPut and creates a sane ULS entry 3. The user deletes the bot (`tctl bots rm ...`) 4. The usermonitor watcher catches the OpDelete and replaces the sane ULS with an empty variant, with no roles or labels. 5. The user recreates the bot (`tctl bots add ...`) 6. One of two events happens first: 1. The usermonitor watcher catches the OpPut and replaces the bad ULS with a sane variant. 2. The bot joins and receives certificates If 6.1 occurs before 6.2, the bot joins normally and receives valid certificates. If 6.2 occurs before 6.2, the bot is issued certs with roles derived from the bad ULS (i.e. empty list) and fails to start due to the invalid cert bundle. In my testing, the race window is ~1 second. I see a ~10% failure rate if the bot is joined within 0.5 seconds of being recreated, and a 50% failure rate if the bot is joined immediately (well, as immediately as tbot can start after `tctl bot add ...` returns). Bot joins generally succeed if there's >= 1 second between recreate and join. The associated teleport.e makes the usermonitor ignore bots so new invalid ULS entries won't be created. However, this isn't sufficient to fix the bug for existing clusters. This PR adds 2 additional fixes: - `GetUserOrLoginState()` always returns the user variant for bots, ignoring any potential ULS. - Deleting a bot now deletes any ULS entry for the bot See also: https://github.com/gravitational/teleport.e/pull/8773 * Fix failing test