The policy scope for authentication can be for an individual service, all of the services in a namespace, or all of the services in a service mesh. Let's go through what happens:

1. The policies are defined at the Citadel level.
2. Pilot translates these policies to Envoy proxies to perform the required authentication mechanisms.

3. Pilot sends the configuration details, such as certificates and keys, to the Envoy proxy asynchronously.
4. As soon as the Proxy attached to a microservice receives the configuration, new authentication artifacts take effect.

Origin authentication is the responsibility of the client application and is used to acquire JWT and attach it to the request. You can define JWT either for any request or for all of the requests except public paths, such as /healtz or /status,  to expose them without authentication. You can also only define JWT for the /admin path and expose all of the others to the public. Since this is application language-specific, we will not go into the details of this.

Transport authentication is implemented through mTLS, and the destination rules defined by Pilot determine which services in the mesh should initiate a TLS connection through the Envoy proxy:

For example, let's say we define the policy for the ns1 namespace for Service-D in Citadel and Pilot pushes the mTLS policy to Service-D and the ns1 namespace and leaves the other services intact. Similarly, two policies are defined for the ns2 namespace. One is for Service-A, while the other is for all except Service-A. Note that the Target: All policy is overridden by the one defined explicitly for Service-A.

The preceding is known as policy enforcement at the namespace level. You could also have policy enforcement at the mesh level, where this will be applied to all the services in a mesh. In such a case, only one policy can be defined to avoid conflict precedence. 

Here is an example of MeshPolicy:

apiVersion: "authentication.istio.io/v1alpha1"
kind: MeshPolicy
metadata:
  name: "default"
spec:
  peers:
  - mtls:

The preceding policy must have the default name since the scope is service mesh wide. There is no targets: section. If you change the kind to Policy and add a namespace to the metadata: section, the targets: section shouldn't be defined since the scope is namespace wide. The targets can be defined to limit the scope at the service level.

The peers: section with mtls: {} is equivalent to mtls: {mode: STRICT} for STRICT mTLS. You could define the PERMISSIVE mode for mtls: like so:

peers:
- mtls:
    mode: PERMISSIVE

STRICT mode only allows HTTPS, while PERMISSIVE mode allows both HTTP and HTTPS.

The following example defines two policies. The first policy, called default, applies mTLS for all of the services in the ns1 namespace:

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: default
  namespace: ns1
spec:
  peers:
  - mtls:{}

However, the following policy removes mTLS from Service-A with the use of targets and by specifying the mTLS mode:

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: SVC-A-mTLS-disable
  namespace: ns1
spec:
  targets:
  - name: Service-A
  peers:
  - mtls:
      mode: DISABLE

Transport authentication, as we explained previously, provides granular control. Transport authentication can be implemented at the Pilot level through the use of destination rules, like so:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1

A destination rule is defined for the productpage service, which defines a v1 subset with a traffic policy of ISTIO_MUTUAL, which is mTLS. The v1 subset we defined here will be used in a virtual service.

As you can see, there are two different implementations for mTLS. Use one for your implementation and stick to it.