* Migrate storage version of security APIs to v1
Signed-off-by: Faseela K <faseela.k@est.tech>
* add release notes
Signed-off-by: Faseela K <faseela.k@est.tech>
---------
Signed-off-by: Faseela K <faseela.k@est.tech>
* Validation: CEL adjusted to allow PolicyTargetReference to target gtwapi GatewayClass
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
* adding releasenote
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
* remove CEL validations for PolicyTargetRef to allow vendor extensions
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
* remove centralized group/kind detail and move to where targetRef is used in resources
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
---------
Signed-off-by: Ian Rudie <ian.rudie@solo.io>
* 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
* Add a new 'workload name' label override
Today, we have a "workload name" concept that ends up in metrics.
This is defaulted to deriving from deployment metadata (Deployment name,
etc).
This approach is not perfect. We cannot always derive an appropriate
name (for instance, a Pod can be created directly!). WorkloadEntry,
which often is equvilent to Pod, is also using the WE name -- generally
we would want a higher order name there.
To fix this, I propose we add a label to explicitly specify the workload
name. This format mirrors the existing canonical-{service,revision}
label.
* regen
This is a bit of a mess since its documented in 3 places * 2 resources.
Meaningful changes:
* Explain registry only != security
* Remove recommendation to use registry_only, but explain why someone
might
int64 in proto is encoded to json as a string. To support this, we make
it accept either form.
Without this, istio fails to write the status. See
https://github.com/istio/istio/pull/52159.
Note: this is only an issue now since we just added schema validation
for status.
* fix re2 link
Signed-off-by: Faseela K <faseela.k@est.tech>
* generate crd
Signed-off-by: Faseela K <faseela.k@est.tech>
---------
Signed-off-by: Faseela K <faseela.k@est.tech>
* 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)
* Allow defining CRDs from a single version
Part of https://github.com/istio/api/issues/3127. Goes with a
corresponding tools change; this will fail until that merges.
This just shows DR. The tool will support both the new and old way (we
can remove the old way if we want), so we don't have to move everything
at once. We will, though. I kept it to one so its easy to review first.
* Move all APIs over
* policy attachment: allow `targetRefs`
Based on https://github.com/kubernetes-sigs/gateway-api/pull/2966. Note
that we do not HAVE to follow the GatewayAPI here; we can make our own
decision. There is, however, a general desire to allow multiple for
ergonomics.
In this proposal, I hide `targetRef`, but the API will remain + be
implemented forever. Implementation cost here is near zero, as we can
easily translate it to a single `targetRefs`; we just hide from docs to
push users toward the new ones.
* codegen
* Align documentation
* consistency
This is the only API we have a `selector` without `targetRef`.
The motivation at the time was that waypoints don't official support
EnvoyFilter, and targetRef was primarily for waypoints.
However, targetRef can be used with all Kubernetes Gateway, including
for ingress, where EnvoyFilter is supported. Also, long term it will
support waypoint as well I assume; the earlier we add the field the less
migration pain there is.
This PR goes directly to `targetRefs` in line with
https://github.com/istio/api/pull/3159.
Francisco Herrera