Add targetRef field to Istio CRDs that use workloadSelector

[MorrisLaw]

These tasks can be done in one PR or in multiple PRs. Only caveat is that the targetRef proto definition needs to exist first before being added as a field to the different places we want to update, so we'll need to add that as a first step.

• Create targetRef proto definition and add it to istio/api/gateway. Gateway directory will be a new directory [UPDATE] it should be added to istio/api/types. The proto definition should look like what's defined in the gateway api spec for PolicyTargetReference: GEP-713: Metaresources and Policy Attachment_metaresource_ - Kubernetes Gateway API (k8s.io)
• add targetRef field to AuthorizationPolicy CRD via proto definition, add any necessary docs within the proto file
• add targetRef field to Telemetry CRD via proto definition, add any necessary docs within the proto file
• add targetRef field to WasmPlugin CRD via proto definition, add any necessary docs within the proto file
• add targetRef field to ProxyConfig CRD via proto definition, add any necessary docs within the proto file UPDATE: Decided not to do this, see comment here.
• add targetRef field to RequestAuthentication CRD via proto definition, add any necessary docs within the proto file

Note: Be sure to run make gen-proto locally after a proto update to ensure the necessary protobuf related files are generated. Documentation in the proto is also referenced by some automation in place which will generate docs off of it. Look at some examples like the PR for jwt.proto to see how documentation within the proto can look. Last but not least, be sure to include release notes.

[howardjohn]

I would not put it under gateway but rather types. It is specific to Gateway today but likely not long term.

[jaellio]

@howardjohn How do we version types? For example, the WorkloadSelector is v1beta1, and is referenced in the v1 AthorizationPolicy. Thanks!

[howardjohn]

It's basically meaningless. Top level types (like AuthorizationPolicy) need to be identical (in yaml) across all versions.

Internal types like workload selector has no relevance for version and probably shouldn't have one at all (but does due to backwards compatible)

[hzxuzhonghu]

Wanna to know what target do we need to support? If i read correctly from other doc, the target is gateway for waypoint.

how could targetref coexist with workload selector if we need to apply a policy both to a workload and service or someother object

[MorrisLaw]

Wanna to know what target do we need to support? If i read correctly from other doc, the target is gateway for waypoint.

how could targetref coexist with workload selector if we need to apply a policy both to a workload and service or someother object

Hey @hzxuzhonghu, I'm not sure I fully understand both of your questions but I'm going to try. Are you referring to the following lines from the doc?

Each resource listed in the Scope section of this proposal will have a new targetRef
field added to their proto. At present gateway.networking.k8s.io/Gateway is the only valid Kind for this field.

It seems like the main question is "How can targetref coexist with workload selector if we need to also apply policy to a workload and service or other objects"?

The document addresses this I believe:

In the waypoint, this means binding policies to the waypoint itself. This will be done by introducing a TargetRef field into all workload selector API types, aligning with the "policy attachment" concept in Gateway API.

There are several Istio CRDs that use workloadSelector; however, not all of them are relevant for Ambient. Thus, the scope for this proposed change is limited to the following resources:
AuthorizationPolicy
Telemetry
WasmPlugin
ProxyConfig
RequestAuthentication

Waypoint proxies will accept label selectors if they match AND there is no targetRef specified

So I think that if NO targetRef is specified, then we'll default to workload selector. BUT if there is a targetRef specified then we'll use that instead. That's how they could co-exist initially. After some number of releases we'll want to switch over to only using targetRef and ignoring label selectors.

cc/ @keithmattix (please fill in any details, or correct me if any of this doesn't make sense)