Enable optional features on managed control plane

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

When you provision managed Cloud 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.

Distroless proxy image

  • If you directly onboarded to Cloud Service Mesh with a managed TRAFFIC_DIRECTOR control plane implementation, then only the distroless image type is supported. You cannot change it.

  • If your fleet originally used the ISTIOD control plane implementation and was migrated to the TRAFFIC_DIRECTOR implementation, your image type was left unchanged during migration, and you can change the image type to distroless yourself.

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 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. However, you can use ephemeral containers to attach to a running workload Pod to be able to inspect it and run custom commands. For example, see Collecting Cloud Service Mesh logs.

The following configuration enables distroless images for the entire Cloud 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

You may override the imageType by using the following pod annotation.

sidecar.istio.io/proxyImageType: debug

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

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Because it does not require a debug base image, most types of proxy debugging should use gcloud beta container fleet mesh debug proxy-status / proxy-config (details).

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.

  1. 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).

  2. You can make the previous necessary config changes in the configmap using the following command:

    kubectl edit configmap istio-release-channel -n istio-system -o yaml
    
  3. Run the following command to view the configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  4. 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 Cloud Service Mesh user authentication for browser-based end-user authentication and access control to your deployed workloads. For more information, see Configuring Cloud 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