Description
Authentication failure listeners can block a caller by IP address or username after a configured threshold is reached. Today, the node that observes enough failures makes and enforces that block decision locally.
In a multi-node cluster, subsequent requests may be routed to another node that has not observed the same failures and therefore does not enforce the block. This makes blocking dependent on load-balancer routing and lets a caller spread attempts across nodes.
When an authentication failure listener triggers a block on one node, propagate that active block to every node in the cluster.
Proposed behavior
- Keep failure counting local unless there is a reason to aggregate it separately; this issue is specifically about distributing a block after a node has triggered it.
- Propagate both IP-based and username-based block decisions.
- Include the block's creation time and expiry so all nodes enforce the same remaining duration rather than starting independent full-duration timers.
- Make active blocks available to nodes that join or restart while the block remains valid.
- Remove or expire a block consistently across the cluster without leaving stale node-local state.
- Use authenticated internal transport and avoid exposing usernames or other block state to unauthorized callers.
- Bound the distributed state and define behavior during cluster-manager changes, network partitions, publication failures, and high-cardinality attacks.
Acceptance criteria
- A block triggered on any node is enforced by all nodes within a defined propagation interval.
- Both configured block dimensions, IP address and username, are supported.
- A caller cannot evade an active block by sending subsequent requests to a different node.
- Expiration uses a cluster-consistent timestamp and does not extend the configured block duration per node.
- Newly joined nodes receive all unexpired blocks.
- Cluster-manager failover and node restart do not silently discard active blocks.
- Audit logging or metrics identify the block origin, propagation outcome, and expiry without leaking sensitive information.
- Multi-node integration tests alternate failed and subsequent requests across nodes and cover trigger, enforcement, expiry, node join, and failover.
Design considerations
Possible mechanisms include cluster-state-backed metadata, a dedicated system index with listeners, or an internal transport broadcast plus reconciliation. The implementation should favor bounded state, reliable convergence, and low overhead on the authentication hot path.
Description
Authentication failure listeners can block a caller by IP address or username after a configured threshold is reached. Today, the node that observes enough failures makes and enforces that block decision locally.
In a multi-node cluster, subsequent requests may be routed to another node that has not observed the same failures and therefore does not enforce the block. This makes blocking dependent on load-balancer routing and lets a caller spread attempts across nodes.
When an authentication failure listener triggers a block on one node, propagate that active block to every node in the cluster.
Proposed behavior
Acceptance criteria
Design considerations
Possible mechanisms include cluster-state-backed metadata, a dedicated system index with listeners, or an internal transport broadcast plus reconciliation. The implementation should favor bounded state, reliable convergence, and low overhead on the authentication hot path.