Skip to content

Collision Detection

This page explains the current per-objective collision logic. The intended policy still lives in the spec.

Problem

Two PerObjective bindings can resolve to the same workload set if they point at the same pool and use the same container discriminator. In that case, distinct objective identities would land on the same container selection.

Current Detection Strategy

For each PerObjective binding in a namespace, the controller renders the identity and computes a collision fingerprint from:

  • the normalized pool-derived pod selector
  • the normalized final selector set
  • containerDiscriminator.type
  • containerDiscriminator.value

Bindings with the same fingerprint are treated as colliding.

Current Outcome

When a collision is detected:

  • every colliding binding gets Conflict=True
  • Ready is forced to False
  • computedSpiffeIDs and renderedSelectors are cleared
  • managed ClusterSPIFFEID resources for those bindings are deleted
  • the controller emits an IdentityCollision warning event

When the collision is resolved:

  • Conflict is reset to False
  • normal reconciliation resumes
  • the controller emits IdentityCollisionResolved

Scope Boundary

The current collision path applies only to PerObjective bindings. PoolOnly bindings bypass that detection path.