Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

관리형 컨트롤 플레인에서 선택적 기능 사용 설정

이 페이지에서는 관리형 Cloud Service Mesh에서 선택적 기능을 사용 설정하는 방법을 설명합니다. 클러스터 내 컨트롤 플레인은 클러스터 내 컨트롤 플레인에서 선택적 기능 사용 설정을 참조하세요.

관리형 Cloud Service Mesh를 프로비저닝할 때 지원되는 기능은 컨트롤 플레인 구현에 따라 다르며 특정 기능은 허용 목록을 통해서만 사용할 수 있습니다. 자세한 내용은 지원되는 기능을 참고하세요. 현재 IstioOperator 기반 구성을 사용하는 경우

Distroless 프록시 이미지

직접 온보딩된 클러스터 (관리형 TRAFFIC_DIRECTOR 컨트롤 플레인에 직접 온보딩된 클러스터): distroless 이미지 유형만 지원됩니다. 이 유형은 변경할 수 없습니다. default 이미지는 지원되지 않습니다.
마이그레이션된 클러스터(ISTIOD에서 TRAFFIC_DIRECTOR 컨트롤 플레인으로 마이그레이션된 클러스터): 이미지 유형은 기본적으로 디버그 바이너리가 포함된 default 이미지로 설정됩니다. 보안을 개선하기 위해 distroless 이미지를 직접 선택할 수 있습니다.

Distroless는 보안 개선을 위해 권장되는 이미지 유형입니다. 컨테이너 런타임의 콘텐츠를 필요한 패키지로만 제한하는 것이 좋습니다. 이 접근 방법은 CVE(Common Vulnerabilities and Exposure) 스캐너의 보안과 신호 대 잡음비를 향상시킵니다. Istio는 distroless 기본 이미지를 기반으로 프록시 이미지를 제공합니다.

distroless 프록시 이미지에는 프록시 이외의 바이너리가 포함되지 않습니다. 따라서 셸을 exec하거나 컨테이너 내에서 curl, ping 또는 기타 디버그 유틸리티를 사용할 수 없습니다. 하지만 임시 컨테이너를 사용하여 실행 중인 워크로드 포드에 연결하여 검사하고 커스텀 명령어를 실행할 수 있습니다. 예시는 Cloud Service Mesh 로그 수집을 참고하세요.

다음 구성은 전체 Cloud Service Mesh에 대해 distroless 이미지를 사용 설정합니다. 이미지 유형 변경이 적용되려면 각 포드가 다시 시작되고 다시 삽입되어야 합니다.

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

다음 포드 주석을 사용하여 imageType을 재정의할 수 있습니다. 관리형 TRAFFIC_DIRECTOR 컨트롤 플레인이 있는 클러스터의 경우 distroless만 명시적 재정의 값으로 지원됩니다 (debug 또는 기타 distroless가 아닌 이미지 유형은 허용되지 않음).

sidecar.istio.io/proxyImageType: distroless

주석을 사용해 배포 이미지 유형을 변경한 후에는 배포를 다시 시작해야 합니다. 기본 이미지로 되돌리려면 MeshConfig에서 sidecar.istio.io/proxyImageType 주석 또는 imageType 필드를 삭제한 후 배포를 다시 시작합니다.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

디버그 기본 이미지가 필요하지 않으므로 대부분의 프록시 디버깅 유형은 gcloud beta container fleet mesh debug proxy-status / proxy-config (세부정보)을 사용해야 합니다.

아웃바운드 트래픽 정책

기본적으로 outboundTrafficPolicy는 ALLOW_ANY로 설정됩니다. 이 모드에서는 모든 외부 서비스에 대한 모든 트래픽이 허용됩니다. 서비스 항목이 정의된 외부 서비스로만 트래픽을 제어하고 제한하려면 ALLOW_ANY의 기본 동작을 REGISTRY_ONLY로 변경할 수 있습니다.

다음 구성은 outboundTrafficPolicy를 REGISTRY_ONLY로 구성합니다.

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

여기서 release-channel은 출시 채널입니다(asm-managed, asm-managed-stable, asm-managed-rapid).

다음 명령어를 사용하여 구성 맵에서 이전에 필요한 구성 변경사항을 적용할 수 있습니다.
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

다음 명령어를 실행하여 구성 맵을 확인합니다.

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

REGISTRY_ONLY로 outboundTrafficPolicy가 사용 설정되었는지 확인하려면 mesh: 섹션에 다음 줄이 표시되는지 확인합니다.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

최종 사용자 인증

배포된 워크로드에 대한 브라우저 기반 최종 사용자 인증 및 액세스 제어를 위해 관리형 Cloud Service Mesh 사용자 인증을 구성할 수 있습니다. 자세한 내용은 Cloud Service Mesh 사용자 인증 구성을 참조하세요.

워크로드의 최소 TLS 버전 구성

관리형 TRAFFIC_DIRECTOR 컨트롤 플레인 구현을 사용하여 Cloud Service Mesh에 직접 온보딩한 경우에는 이 설정을 변경할 수 없습니다.

minProtocolVersion 필드를 사용하여 워크로드 간의 TLS 연결에 대한 최소 TLS 버전을 지정할 수 있습니다. 최소 TLS 버전 설정 및 워크로드의 TLS 구성 확인에 대한 자세한 내용은 Istio 워크로드 최소 TLS 버전 구성을 참조하세요.

다음 예시에서는 워크로드의 최소 TLS 버전을 1.3으로 설정하는 ConfigMap을 보여줍니다.

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