# Enable optional features on managed control plane

> [!NOTE]
> **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](https://docs.cloud.google.com/service-mesh/docs/overview.md.txt).

This page describes how to enable optional features on managed
Cloud Service Mesh. For information on the in-cluster control plane, see
[Enabling optional features on the in-cluster control plane](https://docs.cloud.google.com/service-mesh/v1.21/docs/unified-install/options/enable-optional-features).

> [!CAUTION]
> **Caution:** There is a known issue with the TRAFFIC_DIRECTOR control plane implementation. If you are using that implementation, then you must make changes in the `istio-asm-managed-rapid` configmap, even if you are using a channel other than rapid.

When you provision managed Cloud Service Mesh, supported features differ
based on the control plane implementation, and certain features are only
available via allowlist. See
[supported features](https://docs.cloud.google.com/service-mesh/v1.21/docs/managed/supported-features-mcp) for details.
If you are using an `IstioOperator` based configuration today, the
[Migrate from IstioOperator](https://docs.cloud.google.com/service-mesh/v1.21/docs/migrate-istio-operator) 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](https://docs.cloud.google.com/service-mesh/v1.21/docs/supported-features-managed.md.txt#identify_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](https://github.com/GoogleContainerTools/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. 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](https://docs.cloud.google.com/service-mesh/v1.21/docs/troubleshooting/troubleshoot-collect-logs.md.txt#configure_envoy_proxy).

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.

```yaml
     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.

```yaml
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](https://docs.cloud.google.com/service-mesh/v1.21/docs/troubleshooting/troubleshoot-intro.md.txt)).

## 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](https://istio.io/latest/docs/reference/config/networking/service-entry/)
are defined you can change the default behavior of `ALLOW_ANY` to
`REGISTRY_ONLY`.

> [!WARNING]
> **Warning:** You can overwrite your own changes. If you already have an existing config map, you must include all previous customization settings within the `mesh:` section to preserve your changes.

1. The following configuration configures the `outboundTrafficPolicy` to
   `REGISTRY_ONLY`:

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

   where <var translate="no">release-channel</var> is your [release channel](https://docs.cloud.google.com/service-mesh/docs/managed/select-a-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.

   ```yaml
   ...
   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](https://docs.cloud.google.com/service-mesh/v1.21/docs/security/end-user-auth.md.txt).

## Configure the minimum TLS version for your workloads

If you directly onboarded to Cloud Service Mesh with a managed `TRAFFIC_DIRECTOR`
[control plane implementation](https://docs.cloud.google.com/service-mesh/v1.21/docs/supported-features-managed.md.txt#identify_control_plane_implementation),
then you cannot change this setting.

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](https://preliminary.istio.io/latest/docs/tasks/security/tls-configuration/workload-min-tls-version/).

> [!WARNING]
> **Warning:** The Istio guide linked in the preceding paragraph uses `IstioOperator`, which is not supported by managed Cloud Service Mesh. You must convert the `IstioOperator` to an equivalent `ConfigMap`, such as the following example.

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

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