When users use Gateway API via the Cluster Ingress Operator (CIO), they may look around and realize that we are using Istio (specifically, OpenShift Service Mesh (OSSM)) under the hood.

We document an expectation that only Gateway API resources are available as our supported API surface. This means: if a user decides to try and use Istio specific resources (e.g. VirtualService) with our implementation, this is not allowed or supported. Ideally we would like to detect and thwart attempts to utilize this underlying API surface to make that lack of support extra clear and avoid users relying on it.

The purpose of this spike is to dig in and determine how such a "detector" would work. It ultimately should enable us to at minimum check for this behavior and mark the CIO as "Degraded" if detected.

Additional Requirements

We (eventually) need an exception for Kuadrant, and we anticipate more exceptions being needed over time so we'll need to ensure we have a plan for how we can add exceptions in future releases. Today, Kuadrant specifically needs to be able to use EnvoyFilter and WasmPlugin in order to function with our Gateway API implementation. Related: https://github.com/Kuadrant/kuadrant-operator/issues/1200

We also need an exception for RHOAI 3.0 to use DestinationRules to configure TLS for their ext-proc backends.

Approved exceptions

// kuadrant is allowed to configure our control plane, EnvoyFilter/WASMPlugin for Ratelimit and AuthPolicy
"kuadrant.io/managed": "true"

// RHOAI is allowed to configure our control plane, DestinationRule for EPP, GIE Shadow Service & Model servers
"llm-d.ai/managed": "true",