1.2. 서비스 메시 릴리스 노트

이번 릴리스에서는 ARM 기반 클러스터에서 Red Hat OpenShift Service Mesh Operator를 기술 프리뷰 기능으로 사용할 수 있습니다. 이미지는 Istio, Envoy, Prometheus, Kiali, Grafana에서 사용할 수 있습니다. Jaeger에서 이미지를 사용할 수 없으므로 Jaeger를 서비스 메시 애드온으로 비활성화해야 합니다.

이번 개선된 기능에는 gRPC API를 사용하여 외부 권한 부여 공급자를 구성하기 위해 envoyExtAuthzGrpc 필드가 추가되었습니다.

이번 개선된 기능에는 일반적으로 사용 가능한 클러스터 전체 배포 버전이 도입되었습니다. 클러스터 전체 배포에는 전체 클러스터의 리소스를 모니터링하는 서비스 메시 컨트롤 플레인이 포함되어 있습니다. 컨트롤 플레인은 모든 네임스페이스에서 단일 쿼리를 사용하여 메시 구성에 영향을 주는 각 Istio 또는 Kubernetes 리소스를 모니터링합니다. 클러스터 전체 배포에서 컨트롤 플레인이 수행하는 쿼리 수를 줄이면 성능이 향상됩니다.

이번 개선된 기능에는 meshConfig.discoverySelectors 필드의 일반적으로 사용 가능한 버전이 도입되어 클러스터 전체 배포에서 서비스 메시 컨트롤 플레인에서 검색할 수 있는 서비스를 제한할 수 있습니다.

spec:
  meshConfig
    discoverySelectors:
    - matchLabels:
        env: prod
        region: us-east1
    - matchExpressions:
      - key: app
        operator: In
        values:
          - cassandra
          - spark

이번 업데이트를 통해 Red Hat OpenShift Service Mesh는 cert-manager 컨트롤러 및 istio-csr 에이전트와 통합됩니다. cert-manager 는 인증서 및 인증서 발행자를 Kubernetes 클러스터에서 리소스 유형으로 추가하고 해당 인증서를 획득, 갱신 및 사용하는 프로세스를 단순화합니다. cert-manager 는 Istio의 중간 CA 인증서를 제공하고 순환합니다. istio-csr 과의 통합을 통해 사용자는 Istio 프록시에서 인증서 요청을 cert-manager 에 위임할 수 있습니다. ServiceMeshControlPlane v2.4에서는 cert-manager 에서 cacerts 시크릿으로 제공하는 CA 인증서를 허용합니다.

이번 개선된 기능에는 AuthorizationPolicy 리소스의 action: CUSTOM 필드를 사용하여 Red Hat OpenShift Service Mesh를 외부 권한 부여 시스템과 통합하는 데 일반적으로 사용 가능한 방법이 도입되었습니다. envoyExtAuthzHttp 필드를 사용하여 액세스 제어를 외부 권한 부여 시스템에 위임합니다.

이번 개선된 기능에는 일반적으로 사용 가능한 Prometheus 확장 공급자 버전이 도입되었습니다. spec.meshConfig 사양에서 extensionProviders 필드의 값을 prometheus 로 설정하여 OpenShift Container Platform 모니터링 스택 또는 사용자 정의 Prometheus 설치에 지표를 노출할 수 있습니다. Telemetry 오브젝트는 트래픽 지표를 수집하도록 Istio 프록시를 구성합니다. 서비스 메시는 Prometheus 지표에 대한 Telemetry API만 지원합니다.

spec:
  meshConfig:
    extensionProviders:
    - name: prometheus
      prometheus: {}
---
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-prometheus-metrics
spec:
  metrics:
  - providers:
    - name: prometheus

이번 개선된 기능을 통해 단일 스택 IPv6 클러스터를 일반적으로 지원하여 광범위한 IP 주소에 대한 액세스를 제공합니다. 듀얼 스택 IPv4 또는 IPv6 클러스터는 지원되지 않습니다.

이번 개선된 기능에는 OpenShift Container Platform Gateway API의 업데이트된 기술 프리뷰 버전이 도입되었습니다. 기본적으로 OpenShift Container Platform Gateway API는 비활성화되어 있습니다.

spec:
  techPreview:
    gatewayAPI:
      enabled: true

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"

OpenShift 인프라 노드에서 서비스 메시 컨트롤 플레인 배포가 지원 및 문서화됩니다. 자세한 내용은 다음 설명서를 참조하십시오.

Service Mesh 2.4는 Istio 1.16을 기반으로 하며 새로운 기능 및 제품 개선 사항을 제공합니다. 많은 Istio 1.16 기능이 지원되지만 다음 예외가 표시되어야 합니다.

openshift-operators 네임스페이스에는 새로운 istio CNI DaemonSet istio-cni-node-v2-3 및 새 ConfigMap 리소스 istio-cni-config-v2-3 이 포함됩니다.

Service Mesh Control Plane 2.3으로 업그레이드할 때 기존 istio-cni-node DaemonSet은 변경되지 않으며 새로운 istio-cni-node-v2-3 DaemonSet이 생성됩니다.

이 이름 변경은 이전 릴리스 또는 이전 릴리스를 사용하여 배포된 Service Mesh Control Plane과 연결된 istio-cni-node CNI DaemonSet에는 영향을 미치지 않습니다.

이번 릴리스에서는 게이트웨이 주입에 대한 일반적으로 사용 가능한 지원이 도입되었습니다. 게이트웨이 구성은 서비스 워크로드와 함께 실행되는 사이드카 Envoy 프록시 대신 메시의 에지에서 실행되는 독립 실행형 Envoy 프록시에 적용됩니다. 이를 통해 게이트웨이 옵션을 사용자 지정할 수 있습니다. 게이트웨이 삽입을 사용하는 경우 게이트웨이 프록시를 실행하려는 네임스페이스에 다음 리소스를 만들어야 합니다. Service,Deployment,Role, RoleBinding.

서비스 메시 2.3은 새로운 기능 및 제품 개선 사항을 제공하는 Istio 1.14를 기반으로 합니다. 많은 Istio 1.14 기능이 지원되지만 다음 예외에 유의하십시오.

이번 릴리스에서는 Kiali 인터페이스를 OpenShift 웹 콘솔에 직접 통합하는 OpenShift Container Platform Service Mesh Console의 기술 프리뷰 버전이 도입되었습니다. 자세한 내용은 OpenShift Service Mesh Console 소개(기술 프리뷰)를 참조하십시오.

이번 릴리스에서는 클러스터 전체 배포를 기술 프리뷰 기능으로 도입했습니다. 클러스터 전체 배포에는 전체 클러스터의 리소스를 모니터링하는 Service Mesh Control Plane이 포함되어 있습니다. 컨트롤 플레인은 모든 네임스페이스에서 단일 쿼리를 사용하여 메시 구성에 영향을 미치는 각 Istio 또는 Kubernetes 리소스 종류를 모니터링합니다. 반면 다중 테넌트 접근 방식은 각 리소스 유형에 대해 네임스페이스당 쿼리를 사용합니다. 클러스터 전체 배포에서 컨트롤 플레인이 수행하는 쿼리 수를 줄이면 성능이 향상됩니다.

  apiVersion: maistra.io/v2
  kind: ServiceMeshControlPlane
  metadata:
    name: cluster-wide
    namespace: istio-system
  spec:
    version: v2.3
    techPreview:
      controlPlaneMode: ClusterScoped 1

  apiVersion: maistra.io/v1
  kind: ServiceMeshMemberRoll
  metadata:
    name: default
  spec:
    members:
    - '*' 1

이번 개선된 기능을 통해 주석 복사 외에도 OpenShift 경로의 특정 레이블을 복사할 수 있습니다. Red Hat OpenShift Service Mesh는 Istio Gateway 리소스에 있는 모든 레이블 및 주석( kubectl.kubernetes.io로 시작하는 주석 제외)을 관리형 OpenShift 경로 리소스에 복사합니다.

이 릴리스에서는ECDHEs mPlugin API에 대한 지원이 추가되어 ServiceMeshExtension API를 더 이상 사용하지 않습니다.

이번 릴리스에서는 다중 클러스터 페더레이션을 포함하여 AWS(ROSA)의 Red Hat OpenShift에 대한 서비스 메시 지원을 도입했습니다.

이번 릴리스에서는 istio-node DaemonSet이 업스트림 Istio의 이름과 일치하도록 istio-cni-node 로 이름이 변경되었습니다.

Istio 1.10은 기본적으로 lo 대신 eth0 을 사용하여 애플리케이션 컨테이너로 트래픽을 전송하도록 Envoy를 업데이트했습니다.

이번 릴리스에서는 모든 플랫폼의 서비스 메시 1.1을 기반으로 서비스 메시 컨트롤 플레인에 대한 지원 종료를 표시합니다.

서비스 메시 2.2는 Istio 1.12를 기반으로 하며 새로운 기능 및 제품 개선 사항을 제공합니다. 많은 Istio 1.12 기능이 지원되지만 다음과 같은 지원되지 않는 기능을 고려해야 합니다.

Kubernetes Gateway API는 기본적으로 비활성화되어 있는 기술 프리뷰 기능입니다. Kubernetes API 배포 컨트롤러가 비활성화되어 있는 경우 수신 게이트웨이를 수동으로 배포하고 생성된 게이트웨이 오브젝트에 연결해야 합니다.

Kubernetes API 배포 컨트롤러가 활성화된 경우 게이트웨이 오브젝트가 생성될 때 수신 게이트웨이가 자동으로 배포됩니다.

$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -; }

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"

  apiVersion: gateway.networking.k8s.io/v1alpha2
  kind: Gateway
  metadata:
    name: gateway
  spec:
    addresses:
    - value: ingress.istio-gateways.svc.cluster.local
      type: Hostname

Red Hat OpenShift Service Mesh는 Service Mesh Control Plane 및 애플리케이션 네임스페이스에서 여러 NetworkPolicies 리소스를 자동으로 생성하고 관리합니다. 애플리케이션과 컨트롤 플레인이 서로 통신할 수 있도록 하기 위한 것입니다.

예를 들어 회사 보안 정책을 적용하는 등 NetworkPolicies 리소스의 자동 생성 및 관리를 비활성화하려면 이를 수행할 수 있습니다. ServiceMeshControlPlane 을 편집하여 spec.security.manageNetworkPolicy 설정을 false로 설정할 수 있습니다.

서비스 메시를 통합하기 위해 CRD(Custom Resource Definitions)가 추가되었습니다. 서비스 메시는 동일한 클러스터 또는 다른 OpenShift 클러스터 모두에서 결합될 수 있습니다. 다음과 같은 새 리소스는 다음과 같습니다.

Service Mesh Federation은 AWS의 Red Hat OpenShift Service on AWS (ROSA), Azure Red Hat OpenShift (ARO) 또는 OpenShift Dedicated (OSD) 간에 지원되지 않습니다.

OVN-Kubernetes CNI(Container Network Interface)는 이전에 Red Hat OpenShift Service Mesh 2.0.1에서 기술 프리뷰 기능으로 소개되었으며 이제 OpenShift Container Platform 4.7.32, OpenShift Container Platform 4.8.12 및 OpenShift Container Platform 4.9에서 사용할 수 있도록 Red Hat OpenShift Service Mesh 2.1 및 2.0.x에서 일반적으로 사용할 수 있습니다.

이제 2.0에서 기술 프리뷰로 처음 도입된 ServiceMeshExtensions CRD(Custom Resource Definitions CRD)를 일반적으로 사용할 수 있습니다. CRD를 사용하여 자체 플러그인을 빌드할 수 있지만 Red Hat은 생성하는 플러그인에 대한 지원을 제공하지 않습니다.

Mixer는 Service Mesh 2.1에서 완전히 제거되었습니다. Mixer가 활성화된 경우 Service Mesh 2.0.x 릴리스에서 2.1으로 업그레이드가 차단됩니다. Mixer 플러그인은 WebAssembly Extensions에 포트해야 합니다.

이제 Mixer가 공식적으로 제거되면 OpenShift Service Mesh 2.1에서 3scale mixer 어댑터를 지원하지 않습니다. Service Mesh 2.1으로 업그레이드하기 전에 Mixer 기반 3scale 어댑터 및 추가 Mixer 플러그인을 제거합니다. 그런 다음 ServiceMeshExtension 리소스를 사용하여 Service Mesh 2.1+로 새 3scale WebAssembly 어댑터를 수동으로 설치하고 구성합니다.

3scale 2.11은 WebAssembly 를 기반으로 업데이트된 서비스 메시 통합을 도입합니다.

서비스 메시 2.1은 Istio 1.9를 기반으로 하며, 이로 인해 많은 새 기능과 제품 개선 사항이 제공됩니다. Istio 1.9 대부분의 기능이 지원되지만 다음 예외를 유의해야 합니다.

Red Hat OpenShift Service Mesh가 모든 ServiceMeshControlPlane 조정이 끝나면 이전 리소스를 정리하는 데 사용하는 시간이 단축되었습니다. 이로 인해 ServiceMeshControlPlane 배포가 빨라지고 기존 SMCP에 변경 사항이 보다 신속하게 적용됩니다.

Kiali 1.36에는 다음과 같은 기능 및 향상된 기능이 포함되어 있습니다.

Red Hat OpenShift Service Mesh에는 원격으로 악용할 수 있는 취약점인 CVE-2021-39156 이 포함되어 있습니다. 여기서 URI 경로의 # 문자로 시작하는 URL 섹션이 Istio URI 경로 기반 권한 부여 정책을 우회할 수 있습니다. 예를 들어 Istio 권한 부여 정책은 URI 경로 /user/profile 에 전송된 요청을 거부합니다. 취약한 버전에서 URI 경로 /user/profile#section1 이 있는 요청이 거부 정책 및 경로를 백엔드로 바이패스합니다(정규화된 URI 경로 /user/profile%23section1)으로 인해 보안 문제가 발생할 수 있습니다.

DENY 작업 및 operation.paths.paths와 함께 권한 부여 정책을 사용하거나 ALLOW 작업 및 operation.notPaths 와 함께 권한 부여 정책을 사용하는 경우 이 취약점의 영향을 받습니다.

완화 기능을 사용하면 권한 부여 및 라우팅 전에 요청 URI의 조각 부분이 제거됩니다. 이렇게 하면 URI에 조각이 있는 요청이 내용 부분이 없는 URI를 기반으로 하는 권한 부여 정책을 우회하지 않습니다.

완화 방법의 새 동작을 옵트아웃하려면 URI의 fragment 섹션이 유지됩니다. URI 조각을 유지하도록 ServiceMeshControlPlane 을 구성할 수 있습니다.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

Istio는 호스트 이름 자체와 일치하는 모든 포트 모두에 대한 호스트 이름을 생성합니다. 예를 들어 "httpbin.foo" 호스트의 가상 서비스 또는 게이트웨이는 "httpbin.foo 및 httpbin.foo:*"과 일치하는 구성을 생성합니다. 그러나 정확한 권한 부여 정책은 hosts 또는 notHosts 필드에 지정된 정확한 문자열과만 일치합니다.

규칙에서 호스트 또는 notHosts 를 결정하는 데 정확한 문자열 비교를 사용하여 AuthorizationPolicy 리소스가 있는 경우 클러스터에 영향을 받습니다.

정확한 일치 대신 접두사를 사용하도록 권한 부여 정책 규칙을 업데이트해야 합니다. 예를 들어 첫 번째 AuthorizationPolicy 예제에서 hosts: ["httpbin.com"] 을 hosts: ["httpbin.com:*"] 로 바꿉니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

Istio에는 경로 기반 권한 부여 규칙이 사용될 때 여러 슬래시 또는 이스케이프된 슬래시 문자(%2F 또는 %5C)가 있는 HTTP 요청 경로가 잠재적으로 Istio 권한 부여 정책을 우회할 수 있는 원격으로 악용 가능한 취약점이 포함되어 있습니다.

예를 들어 Istio 클러스터 관리자가 경로 /admin에 있는 요청을 거부하도록 권한 부여 DENY 정책을 정의한다고 가정합니다. //admin URL 경로에 전송된 요청이 권한 부여 정책에서 거부되지 않습니다.

RFC 3986에 따르면 여러 개의 슬래시가 있는 //admin 경로는 기술적으로 /admin과 다른 경로로 처리되어야 합니다. 그러나 일부 백엔드 서비스는 여러 슬래시를 단일 슬래시로 병합하여 URL 경로를 정규화하도록 선택합니다. 이로 인해 권한 부여 정책( //admin이 /admin과 일치하지 않음)을 우회할 수 있으며 사용자는 백엔드의 /admin 경로에 있는 리소스에 액세스할 수 있습니다. 결과적으로 이는 보안 문제로 나타날 수 있습니다.

ALLOW action + notPaths 필드 또는 DENY action + paths field 경로 필드 패턴을 사용하는 권한 부여 정책이 있는 경우 클러스터는 이 취약점의 영향을 받습니다. 이러한 패턴은 예기치 않은 정책 우회에 취약합니다.

다음과 같은 경우 클러스터는 이 취약점의 영향을 받지 않습니다.

Istio 권한 부여 정책은 HTTP 요청의 URL 경로를 기반으로 할 수 있습니다. URI 정규화라고도 하는 경로 정규화는 들어오는 요청의 경로를 수정 및 표준화하여 정규화된 경로를 표준 방식으로 처리할 수 있도록 합니다. 구문적으로 경로 정규화 후에는 다른 경로가 동일할 수 있습니다.

Istio는 권한 부여 정책에 대해 평가하고 요청을 라우팅하기 전에 요청 경로에서 다음 정규화 체계를 지원합니다.

정규화 알고리즘은 다음 순서로 수행됩니다.

Envoy는 백엔드 서비스의 기대치와 일치하도록 요청 경로를 표준화하여 시스템 보안에 매우 중요합니다. 다음 예제는 시스템을 구성하기 위한 참조로 사용할 수 있습니다. 정규화된 URL 경로 또는 NONE이 선택된 경우 원래 URL 경로는 다음과 같습니다.

Red Hat OpenShift Service Mesh에 대한 경로 정규화를 구성하려면 ServiceMeshControlPlane에서 다음을 지정합니다. 시스템 설정을 결정하는 데 도움이 되도록 구성 예제를 사용합니다.

spec:
  techPreview:
    global:
      pathNormalization: <option>

일부 환경에서는 대/소문자를 구분하지 않는 권한 부여 정책의 경로를 사용하는 것이 유용할 수 있습니다. 예를 들어 https://myurl/get 및 https://myurl/GeT을 동일한 방법으로 처리합니다. 이 경우 아래에 표시된 EnvoyFilter를 사용할 수 있습니다. 이 필터는 비교에 사용되는 경로와 애플리케이션에 제공되는 경로를 모두 변경합니다. 이 예제에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

EnvoyFilter 를 파일에 저장하고 다음 명령을 실행합니다.

$ oc create -f <myEnvoyFilterFile>

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end