Expected behavior:
tctl lock should validate whether the specified target entity (e.g. --server-id, --device, --user, --role) exists in the cluster inventory, and return an error or print a warning if no matching resource is found.
Current behavior:
tctl lock silently accepts arbitrary or non-existent strings for all target flags and creates an active lock resource.
This can create false assurance during incident response. For example, an operator can accidentally pass a node UUID into --device instead of --server-id; tctl reports success and tctl get locks displays an active lock, leading responders to believe a compromised node is quarantined when it remains fully active.
Bug details:
Teleport version: 18.10.4
Recreation steps:
Attempt to lock a non-existent device: tctl lock --device fake_uuid
Attempt to lock a non-existent server ID: tctl lock --server-id fake_uuid
Inspect cluster locks: tctl get locks
Expected behavior:
tctl lock should validate whether the specified target entity (e.g. --server-id, --device, --user, --role) exists in the cluster inventory, and return an error or print a warning if no matching resource is found.
Current behavior:
tctl lock silently accepts arbitrary or non-existent strings for all target flags and creates an active lock resource.
This can create false assurance during incident response. For example, an operator can accidentally pass a node UUID into --device instead of --server-id; tctl reports success and tctl get locks displays an active lock, leading responders to believe a compromised node is quarantined when it remains fully active.
Bug details:
Teleport version: 18.10.4
Recreation steps:
Attempt to lock a non-existent device: tctl lock --device fake_uuid
Attempt to lock a non-existent server ID: tctl lock --server-id fake_uuid
Inspect cluster locks: tctl get locks