// MutatingWebhookConfiguration kubernetes object. This is exposed for
// integration tests only
type MutatingWebhookConfigInfo struct {
	Name     string `json:"name"`
	Revision string `json:"revision"`
	Tag      string `json:"tag,omitempty"`
}

// NsInfo represents namespace related information like pods running there.
// It is used to display data and is exposed for integration tests.
type NsInfo struct {

bin/protoc-min-version*
bin/protoc-gen-docs*
bin/testlinter
bin/envvarlinter
bin/istioctl
*.orig
# Avoid accidental istio.VERSION changes
istio.VERSION
LICENSES.txt
# Proxy generated proxy config in integration test
tests/integration/component/proxy/envoy.conf
**/var/run/secrets/
# Certs generated by testing
security/cmd/node_agent/na/cert_file
security/cmd/node_agent/na/pkey
# istioctl bash completion file
tools/istioctl.bash

  fail "Unable to generate the CRDs for ${GATEWAY_VERSION}. Not updating the CRD file.";
fi

rm -f "${ROOTDIR}/tests/integration/pilot/testdata/gateway-api-crd.yaml"

all CRDs to be present. On each upgrade it is recommended to reapply the file, to make sure
you get all CRDs.  CRDs are separated by release and by component type in the CRD directory.

Istio has strong integration with certmanager.  Some operators may want to keep their current certmanager
CRDs in place and not have Istio modify them. In this case, it is necessary to apply CRD files individually.

```bash

# deb, rpm, etc packages
include tools/packaging/packaging.mk

#-----------------------------------------------------------------------------
# Target: integration tests
#-----------------------------------------------------------------------------
include tests/integration/tests.mk

#-----------------------------------------------------------------------------
# Target: bookinfo sample

	dep "istio.io/istio/tools/istio-iptables/pkg/dependencies"
)

var log = istiolog.RegisterScope("ambient", "ambient controller")

// Adapts CNI to ztunnel server. decoupled from k8s for easier integration testing.
type NetServer struct {
	ztunnelServer        ZtunnelServer
	currentPodSnapshot   *podNetnsCache
	iptablesConfigurator *iptables.IptablesConfigurator
	podNs                PodNetnsFinder

/tests/integration/conformance/                                  @istio/wg-test-and-release-maintainers
/tests/integration/framework/                                    @istio/wg-test-and-release-maintainers
/tests/integration/galley/                                       @istio/wg-networking-maintainers

from the in-cluster IstioOperator custom resource (CR).
There are two major differences:

1. The controller does not accept any dynamic user config through flags. All user interaction is through the
IstioOperator CR.
1. The controller has additional logic that mirrors istioctl commands like upgrade, but is driven from the declarative
API rather than command line.

### Quick tour of CLI commands

  // This field can only be set when the Service type is 'LoadBalancer'. If not set, the default load
  // balancer implementation is used, today this is typically done through the cloud provider integration,
  // but should apply for any default implementation. If set, it is assumed that a load balancer
  // implementation is watching for Services with a matching class. Any default load balancer

This is critical to ensure that a compromised node does not compromise the entire mesh.

This CA enforcement is done by Istio's CA, and is a requirement for any alternative CAs integrating with Ztunnel.

Note: Ztunnel authenticates to the CA with a Kubernetes Service Account JWT token, which encodes the pod information, which is what enables this.