* 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
Previously, only a Gateway resource was defined as a supported
attachment type. This PR updates the API docs to include a Service
as a supported type and also fixes an incorrect link to Gateway API
documentation.
Signed-off-by: Daneyon Hansen <daneyon.hansen@solo.io>
* 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
There is no reason for this to be split, it just makes the docs more
confusing.
I am fairly sure this change only impacts the HTML, merging two pages
into one. I tested with istio.io/istio still builds fine.
* 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
Francisco Herrera