* AuthorizationPolicy: add `serviceAccounts` field
This is a minor implementation complexity in favor of a dramatic
simplification to usage of Istio authorization.
Today, if a user wants to dive into zero-trust 101, they are presented
with a requirement to set `principals`: `A list of peer identities
derived from the peer certificate`, and write
`<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>`.
This simple sentance is a huge cognitive overload for users in my
experience working with users, and unnecesarily pushes SPIFFE, trust
domains, and other unneccesary concepts onto users. Additionally, the
requirement to set 'trust domain', which is overwhelmingly not desired
by users who just want SA auth, leads to all sorts of wonky workarounds
in Istio like `cluster.local` being a magic value.
Instead, we just add a SA field directly. This takes the format `ns/sa`,
as you cannot safely reference a SA without a namespace field as well.
Note we do this, rather than just require you to set 'service account' and 'namespace'
as individual fields, since you could have `namespace=[a,b],sa=[d,e]`
which is ambiguous.
If this is directionally approved, I will add some more documentation
and CEL validation and testing.
* Tests and validation
* add doc
* Clarify comment that this is a KSA
* Fix CEL validation on older k8s versions
Also add testing so we can catch this (though its tied to a single k8s
version, so its not perfect -- but should be able to catch most cases).
CEL before k8s 1.30 did not estimate the cost correctly so its basically
impossible
* actually keep it
* Validate wildcard label selectors
* More CEL improvements
This gives WasmPlugin and Telemetry full parity with the webhook.
Verified by fuzzing, which I will merge into istio/istio after this
(tests fail before this lands)
Francisco Herrera