Support for Istio Ambient Mode

[l-rossetti]

Is your feature request related to a problem? Please describe:
Otterize seems not to support Istio ambient mode (without sidecar), released in GA in 2024. This is a blocker for the Otterize integration in our platform.

Describe the solution you'd like:
Otterize to generate from ClientIntents the correct authorization policies for Istio ambient mode, handling both L4 and L7 traffic.

Describe alternatives you've considered:
Manually generating Istio AuthorizationPolicies without Otterize.

Environment details (remove if not applicable):

• Kubernetes version: 1.30
• Cloud-provider/provisioner: EKS with VPC CNI
• Intents-operator version: v3.0.0
• Install method: helm

Additional context:
Hello,

I am currently testing Otterize for generating Istio policies, but I have encountered an issue.

My Istio deployment is configured in Ambient Mode (Istio Ambient Architecture), meaning there are no sidecars in the environment. I did not find any documentation in Otterize explicitly stating the lack of support for the ambient mesh configuration. However, Otterize seems unable to generate AuthorizationPolicies because it looks for a sidecar named "istio-proxy" in the pods that need protection. Since, according to Ambient Mode specifications, this sidecar does not exist, the following error is returned from the intents-operator:
🔗 Relevant Line in intents-operator

To test a workaround, I added an empty container named "istio-proxy" to my pods. With this change, the AuthorizationPolicy was created. However, HTTP traffic with mTLS termination is blocked, even though I have explicitly defined a ClientIntent to allow this traffic. Test workloads correctly follow the label mechanism as described here.

AuthorizationPolicy status:

ztunnel does not support HTTP rules (methods, paths require HTTP parsing), in ambient mode you must use waypoint proxy to enforce HTTP rules. Allow rules with HTTP attributes will be empty and never match. This is more restrictive than requested.

The policy does not take care of the waypoint proxy deployed that should handle the request.

ClientIntent:

apiVersion: k8s.otterize.com/v2beta1
kind: ClientIntents
metadata:
  annotations:
    intents.otterize.com/client-intents-service-account: default
    intents.otterize.com/service-missing-sidecar: "false"
    intents.otterize.com/shared-service-account: "true"
  name: client
  namespace: otterize-test-istio-ambient
spec:
  targets:
  - kubernetes:
      http:
      - methods:
        - GET
        path: /
      kind: Service
      name: server
  - kubernetes: # not sure this one is really needed
      kind: Gateway
      name: waypoint
  workload:
    kind: Deployment
    name: client

Issue Analysis
Otterize does not generate AuthorizationPolicies when the "istio-proxy" container is missing.
Forcing the creation of the AuthorizationPolicy (by adding a fake istio-proxy container) results in a broken policy that prevents L7 traffic from flowing through the Waypoint Gateway.
The generated policy only controls L4 traffic through ztunnel, rather than properly handling L7 traffic via Waypoint.

Feature Request
Is support for Istio Ambient Mode on Otterize’s roadmap, considering it was released as GA in 2024?
Is there a way to expedite support for Ambient Mode, as this issue is a blocker for using Otterize with Istio in this configuration?

Thanks in advance! 🚀