Discussion: XAccessPolicy Acceptance Model (All-or-Nothing vs. Per-Target)

[chuangw6]

Original thread: #127 (comment)

We currently enforce a limit (MaxAccessPoliciesPerTarget = 5) on the number of AccessPolicies that can target a single resource (Gateway or XBackend). This limit prevents resource bloat in the Envoy proxy configuration and ensures predictable performance of the RBAC filter chain.

We currently use an all-or-nothing model: if an XAccessPolicy exceeds the limit for any target, it is globally rejected. Part of the reason is starting with this model is safer and provides a cleaner migration path if we decide to move toward granular "Partial Rejects" in the future, than it is to go the other direction, which would be highly disruptive for users.

See the trade-offs below between atomic intent and per-target resiliency, and feel free to share your thoughts.

Option 1: All-or-Nothing (Atomic) - Current Approach

• Pros: Deterministic and simple; treats the policy as a single atomic unit of intent.
• Cons:
  • Collateral Damage: One crowded target-ref breaks the policy for all other valid targets.
  • Inversion of Logic: Users see "Limit Exceeded" errors on healthy targets due to failures elsewhere.
  • Resource Bloat: Encourages users to create many single-target policies to avoid "blast radius" risks.

Option 2: Per-Target (Granular)

• Pros: High resiliency; valid targets remain secured regardless of failures on other targets.
• Cons:
  • Ghost States: Creates "half-working" policies that are complex to interpret in the status field.
  • Operational Messiness: Significantly complicates controller logic and status tracking (Ancestors).
  • Inconsistent Intent: Creates a scenario where a user's intent is only partially realized, which might be dangerous in security contexts where a user expects a rule to be applied "everywhere or nowhere."

[haiyanmeng]

/assign @haiyanmeng