Enable optional features on managed Anthos Service Mesh

This page describes how to enable optional features on a managed Anthos Service Mesh control plane. For information on the in-cluster control plane, see Enabling optional features on the in-cluster control plane.

When you provision managed Anthos Service Mesh, the features that are enabled by default differ by platform. If you are using an IstioOperator based configuration today, the Migrate from IstioOperator tool can help convert to the configuration supported by the managed control plane.

Envoy access logs

Run the following commands to enable Envoy access logging:

Run the following command to add accessLogFile: /dev/stdout:

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

where release-channel is your release channel (asm-managed, asm-managed-stable, or asm-managed-rapid).

Run the following command to view the configmap:

kubectl get configmap istio-release-channel -n istio-system -o yaml

To verify that access logging is enabled, ensure the accessLogFile: /dev/stdout line appears in the mesh: section.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Enable Cloud Tracing

Run the following commands to enable Cloud Trace:

Run the following command:

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      tracing:
        stackdriver: {}
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

where release-channel is your release channel (asm-managed, asm-managed-stable, or asm-managed-rapid).

Run the following command to view the configmap:

kubectl get configmap istio-release-channel -n istio-system -o yaml

To verify that Cloud Trace is enabled, ensure the following lines appear in the mesh: section.

...
apiVersion: v1
data:
  mesh: |
    ....
    defaultConfig:
      tracing:
        stackdriver:{}
...

Restart the proxies.

Note that currently tracer configuration is part of the proxy bootstrap configuration, so each pod needs to restart and get re-injected to pick up the tracer update. For example, you can use the following command to restart pods that belong to a deployment:
```
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
```

For more information on supported trace headers see Accessing traces.

Distroless proxy image

As a best practice, you should restrict the contents of a container runtime to only the necessary packages. This approach improves security and the signal-to-noise ratio of Common Vulnerabilities and Exposures (CVE) scanners. Istio provides proxy images based on distroless base images.

The following configuration enables distroless images for the entire Anthos Service Mesh. An image type change requires each pod to restart and get re-injected to take effect.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

The distroless proxy image does not contain any binaries other than the proxy. It is therefore not possible to exec a shell or use curl, ping, or other debug utilities inside the container. If you need access to these tools for a specific deployment, you may override the imageType by using the following pod annotation.

sidecar.istio.io/proxyImageType: debug

After changing the image type of a deployment via the annotation, the deployment should be restarted.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

For most types of proxy debugging, istioctl proxy-cmd should be used which does not require a debug base image.

Outbound Traffic Policy

By default outboundTrafficPolicy is set to ALLOW_ANY. In this mode, all traffic to any external service is allowed. To control and restrict the traffic to only the external services for which service entries are defined you can change the default behavior of ALLOW_ANY to REGISTRY_ONLY

The following configuration configures the outboundTrafficPolicy to REGISTRY_ONLY

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: istio-release-channel
    namespace: istio-system
  data:
    mesh: |-
      outboundTrafficPolicy:
       mode: REGISTRY_ONLY

where release-channel is your release channel (asm-managed, asm-managed-stable, or asm-managed-rapid).

You can make the necessary above config changes in the configmap using the below command
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Run the following command to view the configmap:

kubectl get configmap istio-release-channel -n istio-system -o yaml

To verify that outboundTrafficPolicy is enabled with REGISTRY_ONLY, ensure the following lines appear in the mesh: section.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

End user authentication

You can configure managed Anthos Service Mesh user authentication for browser-based end-user authentication and access control to your deployed workloads. For more information, see Configuring Anthos Service Mesh user authentication.

Configure the minimum TLS version for your workloads

You can use the minProtocolVersion field to specify the minimum TLS version for the TLS connections among your workloads. For more information on setting the minimum TLS version and checking the TLS configuration of your workloads, see Istio Workload Minimum TLS Version Configuration.

The following example shows a ConfigMap setting the minimum TLS version for workloads to 1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3