apiVersion: release-notes/v2
kind: feature
area: security
releaseNotes:
  - |

apiVersion: release-notes/v2
kind: bug-fix
area: traffic-management
releaseNotes:
  - |

  // +optional
  optional k8s.io.apimachinery.pkg.apis.meta.v1.ObjectMeta metadata = 1;

  // handler specifies the underlying runtime and configuration that the CRI
  // implementation will use to handle pods of this class. The possible values
  // are specific to the node & CRI configuration.  It is assumed that all
  // handlers are available on every node, and handlers of the same name are

apiVersion: release-notes/v2
kind: bug-fix
area: traffic-management

issue:
  - https://github.com/kubernetes-sigs/gateway-api/issues/2309

releaseNotes:
- |
  **Fixed** Istio's Gateway API implementation to adhere to the Gateway API
  requirement that a `group: ""` field must be set for a `parentRef` of `kind: Service`.
  Istio previously tolerated the missing group for Service-kind parent references. This

					suite.GatewayHTTPConformanceProfileName,
					suite.GatewayTLSConformanceProfileName,
					suite.GatewayGRPCConformanceProfileName,
					suite.MeshHTTPConformanceProfileName,
				),
				Implementation: confv1.Implementation{
					Organization: "istio",
					Project:      "istio",
					URL:          "https://istio.io/",
					Version:      istioVersion,
					Contact:      []string{"@istio/maintainers"},
				},

releaseNotes:
  - |
    **Improved** the ordering of HTTP and TCP envoy filters to improve consistency
upgradeNotes:
  - title: "Envoy filter ordering"
    content: |
      This change impacts internal implementation of how Envoy "filters" are ordered. These filters run in order to implement various functionality.
      
      The ordering is now consistent across inbound, outbound and gateway proxy modes, as well as HTTP and TCP protocols:

# PeerAuthentication Implementation in Ambient

  // +optional
  optional k8s.io.apimachinery.pkg.apis.meta.v1.ObjectMeta metadata = 1;

  // handler specifies the underlying runtime and configuration that the CRI
  // implementation will use to handle pods of this class. The possible values
  // are specific to the node & CRI configuration.  It is assumed that all
  // handlers are available on every node, and handlers of the same name are

For consistency, the same profiles are used across each chart, even if they do not impact a given chart.

Explicitly set values have highest priority, then profile settings, then chart defaults.

As an implementation detail of profiles, the default values for the chart are all nested under `defaults`.
When configuring the chart, you should not include this.

For consistency, the same profiles are used across each chart, even if they do not impact a given chart.

Explicitly set values have highest priority, then profile settings, then chart defaults.

As an implementation detail of profiles, the default values for the chart are all nested under `defaults`.
When configuring the chart, you should not include this.