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

 at the discretion of the release managers if PRs will be accepted and merged into the release branch.
* All code merged in after the feature freeze must have an associated GitHub issue and a release note (exception for
  unit and integration test changes).
    * The release managers may not know of all the features being worked on for an Istio release. Developers must
      make their case as to why their PR should be merged.

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

/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 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.

  // 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

  // For many clients the singular form of the resource will be more understandable to users reading messages and should be used when integrating the name of the resource into a sentence.
  // The command line tool kubectl, for example, allows use of the singular resource name in place of plurals.