관리형 Cloud Service Mesh를 프로비저닝할 때 지원되는 기능은 컨트롤 플레인 구현에 따라 다르며 특정 기능은 허용 목록을 통해서만 사용할 수 있습니다. 자세한 내용은 지원되는 기능을 참고하세요.
현재 IstioOperator 기반 구성을 사용하는 경우 IstioOperator에서 마이그레이션 도구를 사용하면 관리형 제어 영역에서 지원되는 구성으로 변환할 수 있습니다.
Distroless 프록시 이미지
관리형 TRAFFIC_DIRECTOR컨트롤 플레인 구현으로 Cloud Service Mesh에 직접 온보딩한 경우 distroless 이미지 유형만 지원됩니다. 변경은 불가능합니다.
Fleet에서 원래 ISTIOD 컨트롤 플레인 구현을 사용했고 TRAFFIC_DIRECTOR 구현으로 마이그레이션된 경우 이미지 유형은 마이그레이션 중에 변경되지 않으며 이미지 유형을 직접 distroless로 변경할 수 있습니다.
컨테이너 런타임의 콘텐츠를 필요한 패키지로만 제한하는 것이 좋습니다. 이 접근 방법은 CVE(Common Vulnerabilities and Exposure) 스캐너의 보안과 신호 대 잡음비를 향상시킵니다.
Istio는 distroless 기본 이미지를 기반으로 프록시 이미지를 제공합니다.
distroless 프록시 이미지에는 프록시 이외의 바이너리가 포함되지 않습니다.
따라서 셸을 exec하거나 컨테이너 내에서 curl, ping 또는 기타 디버그 유틸리티를 사용할 수 없습니다. 하지만 임시 컨테이너를 사용하여 실행 중인 워크로드 포드에 연결하여 검사하고 커스텀 명령어를 실행할 수 있습니다. 예시는 Cloud Service Mesh 로그 수집을 참고하세요.
다음 구성은 전체 Cloud Service Mesh에 대해 distroless 이미지를 사용 설정합니다.
이미지 유형 변경이 적용되려면 각 포드가 다시 시작되고 다시 삽입되어야 합니다.
디버그 기본 이미지가 필요하지 않으므로 대부분의 프록시 디버깅 유형은 gcloud beta container fleet mesh debug proxy-status / proxy-config(세부정보)를 사용해야 합니다.
아웃바운드 트래픽 정책
기본적으로 outboundTrafficPolicy는 ALLOW_ANY로 설정됩니다. 이 모드에서는 모든 외부 서비스에 대한 모든 트래픽이 허용됩니다. 서비스 항목이 정의된 외부 서비스로만 트래픽을 제어하고 제한하려면 ALLOW_ANY의 기본 동작을 REGISTRY_ONLY로 변경할 수 있습니다.
다음 구성은 outboundTrafficPolicy를 REGISTRY_ONLY로 구성합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["Enable optional features on managed control plane **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- 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\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\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\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"]]
