Keith Mattix II
Keith Mattix II
/cc @linsun this definitely feels like a beta blocker. Should the entirety of the [Ambient APIs doc](https://docs.google.com/document/d/1Lk1I1qB-XwVWFP0sVcIN5JMJZHjuF3j8lGWtUeDK6pY/edit#heading=h.nluvz4y67j4c) be considered a blocker for beta?
In Ambient `PeerAuthentication`s are translated to AuthorizationPolicies executed on ztunnel. Due to the fact that ztunnel doesn't currently apply policy [before](https://github.com/istio/ztunnel/blob/master/src/proxy/inbound_passthrough.rs#L100) or [after](https://github.com/istio/ztunnel/blob/f9272ec8100c4526a1695e2cf84f8f8863a1f1b0/src/proxy/inbound.rs#L293) hairpinning of an unmeshed (i.e. plaintext, non-HBONE)...
Design doc is located [here](https://docs.google.com/document/d/1EDnk9cyji8GtpK7tF6czqiStd7UTujoIhhBUi1XYAQM/edit#heading=h.stll71jzvhaf). Let's consider this the parent issue for layer targeted AuthZ policy since it presents the problem pretty well
I think this is done right?
I may be misremembering, but isn't there a function that strips unnecessary fields before computing the push context? Could this be solved by just adding Status to that set?
/cc @jaellio
> DISABLE in ambient does not actually disable capture, it is ignored/deprecated Currently, DISABLE is equivalent to permissive in Ambient rather than ignored
Well, PeerAuthentication's Ambient support does include port level granularity for STRICT and PERMISSIVE today. But both require 100% traffic capture which I think is more of what you're wanting to...
/cc @whitneygriffith