[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-19。"],[],[],null,["# Enable optional features on managed control plane\n=================================================\n\n| **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](/service-mesh/docs/overview).\n\nThis page describes how to enable optional features on managed\nCloud Service Mesh. For information on the in-cluster control plane, see\n[Enabling optional features on the in-cluster control plane](/service-mesh/docs/unified-install/options/enable-optional-features).\n| **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.\n\nWhen you provision managed Cloud Service Mesh, supported features differ\nbased on the control plane implementation, and certain features are only\navailable via allowlist. See\n[supported features](/service-mesh/docs/managed/supported-features-mcp) for details.\nIf you are using an `IstioOperator` based configuration today, the\n[Migrate from IstioOperator](/service-mesh/docs/migrate-istio-operator) tool can help\nconvert to the configuration supported by the managed control plane.\n\nDistroless proxy image\n----------------------\n\n- If you directly onboarded to Cloud Service Mesh with a managed `TRAFFIC_DIRECTOR`\n [control plane implementation](/service-mesh/docs/supported-features-managed#identify_control_plane_implementation),\n then only the distroless image type is supported. You cannot change it.\n\n- If your fleet originally used the `ISTIOD` control plane implementation and was\n migrated to the `TRAFFIC_DIRECTOR` implementation, your image type was left unchanged\n during migration, and you can change the image type to distroless yourself.\n\nAs a best practice, you should restrict the contents of a container runtime to\nonly the necessary packages. This approach improves security and the\nsignal-to-noise ratio of Common Vulnerabilities and Exposures (CVE) scanners.\nIstio provides proxy images based on [distroless base images](https://github.com/GoogleContainerTools/distroless).\n\nThe distroless proxy image does not contain any binaries other than the proxy.\nIt is therefore not possible to `exec` a shell or use `curl`, `ping`, or other\ndebug utilities inside the container. However, you can use ephemeral containers\nto attach to a running workload Pod to be able to inspect it and run custom\ncommands. For example, see\n[Collecting Cloud Service Mesh logs](/service-mesh/docs/troubleshooting/troubleshoot-collect-logs#configure_envoy_proxy).\n\nThe following configuration enables distroless images for the entire Cloud Service Mesh.\nAn image type change requires each pod to restart and get re-injected to take effect. \n\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: istio-\u003cvar translate=\"no\"\u003erelease-channel\u003c/var\u003e\n namespace: istio-system\n data:\n mesh: |-\n defaultConfig:\n image:\n imageType: distroless\n\nYou may override the `imageType` by using the following pod annotation. \n\n sidecar.istio.io/proxyImageType: debug\n\nAfter changing the image type of a deployment using the annotation, the\ndeployment should be restarted. \n\n```\nkubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME\n```\n\nBecause it does not require a debug base image, most types of proxy debugging\nshould use `gcloud beta container fleet mesh debug proxy-status / proxy-config`\n([details](/service-mesh/docs/troubleshooting/troubleshoot-intro)).\n\nOutbound Traffic Policy\n-----------------------\n\nBy default `outboundTrafficPolicy` is set to `ALLOW_ANY`. In this mode, all\ntraffic to any external service is allowed. To control and restrict the traffic\nto only the external services for which\n[service entries](https://istio.io/latest/docs/reference/config/networking/service-entry/)\nare defined you can change the default behavior of `ALLOW_ANY` to\n`REGISTRY_ONLY`.\n| **Warning:** You can overwrite your own changes. If you already have an existing configmap, you must include all previous customization settings within the `mesh:` section to preserve your changes.\n\n1. The following configuration configures the `outboundTrafficPolicy` to\n `REGISTRY_ONLY`:\n\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: istio-\u003cvar translate=\"no\"\u003erelease-channel\u003c/var\u003e\n namespace: istio-system\n data:\n mesh: |-\n outboundTrafficPolicy:\n mode: REGISTRY_ONLY\n\n where \u003cvar translate=\"no\"\u003erelease-channel\u003c/var\u003e is your [release channel](/service-mesh/docs/managed/select-a-release-channel)\n (`asm-managed`, `asm-managed-stable`, or `asm-managed-rapid`).\n2. You can make the previous necessary config changes in the configmap using the\n following command:\n\n ```\n kubectl edit configmap istio-release-channel -n istio-system -o yaml\n ```\n3. Run the following command to view the configmap:\n\n ```\n kubectl get configmap istio-release-channel -n istio-system -o yaml\n ```\n4. To verify that `outboundTrafficPolicy` is enabled with `REGISTRY_ONLY`, ensure\n the following lines appear in the `mesh:` section.\n\n ...\n apiVersion: v1\n data:\n mesh: |\n outboundTrafficPolicy:\n mode: REGISTRY_ONLY\n ...\n\nEnd user authentication\n-----------------------\n\nYou can configure managed Cloud Service Mesh user authentication for\nbrowser-based end-user authentication and access control to your deployed\nworkloads. For more information, see\n[Configuring Cloud Service Mesh user authentication](/service-mesh/docs/security/end-user-auth).\n\nConfigure the minimum TLS version for your workloads\n----------------------------------------------------\n\nIf you directly onboarded to Cloud Service Mesh with a managed `TRAFFIC_DIRECTOR`\n[control plane implementation](/service-mesh/docs/supported-features-managed#identify_control_plane_implementation),\nthen you cannot change this setting.\n\nYou can use the `minProtocolVersion` field to specify the minimum TLS version\nfor the TLS connections among your workloads. For more information on setting\nthe minimum TLS version and checking the TLS configuration of your workloads,\nsee [Istio Workload Minimum TLS Version Configuration](https://preliminary.istio.io/latest/docs/tasks/security/tls-configuration/workload-min-tls-version/).\n| **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.\n\nThe following example shows a `ConfigMap` setting the minimum TLS version for\nworkloads to 1.3: \n\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: istio-\u003cvar translate=\"no\"\u003erelease-channel\u003c/var\u003e\n namespace: istio-system\n data:\n mesh: |-\n meshMTLS:\n minProtocolVersion: TLSV1_3"]]