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

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

이번 릴리스에서는 WasmPlugin API를 지원하고 ServiceMeshExtention 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는 기본적으로 비활성화되어 있는 기술 프리뷰 기능입니다.

기능을 활성화하려면 ServiceMeshControlPlane 에서 Istiod 컨테이너에 대해 다음 환경 변수를 설정합니다.

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

게이트웨이 API 리스너에 대한 경로 연결 제한은 SameNamespace 또는 All 설정을 사용하여 수행할 수 있습니다. Istio는 listeners.allowedRoutes.namespaces 의 라벨 선택기 사용을 무시하고 기본 동작(SameNamespace)으로 되돌립니다.

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

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

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

서비스 메시 페더레이션은 ROSA(Red Hat OpenShift Service on AWS), Azure Red Hat OpenShift(ARO) 또는 OSD(OpenShift Dedicated)의 클러스터 간에 지원되지 않습니다.

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 Definition)를 이제 일반적으로 사용할 수 있습니다. CRD를 사용하여 고유한 플러그인을 빌드할 수 있지만 Red Hat은 사용자가 생성한 플러그인을 지원하지 않습니다.

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

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

3scale 2.11에는 WebAssembly 를 기반으로 업데이트된 Service Mesh 통합이 도입되었습니다.

Service Mesh 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 경로에 있는 URI 끝에 있는 HTTP 요청은 Istio URI 경로 기반 권한 부여 정책을 무시할 수 있습니다. 예를 들어 Istio 권한 부여 정책은 URI 경로 /user/profile 으로 전송된 요청을 거부합니다. 취약한 버전에서 URI 경로 /user/profile#section1 이 있는 요청은 거부 정책 및 경로를 백엔드로 무시합니다(정규화된 URI 경로 /user/profile%23section1사용) 보안 문제로 이어질 수 있습니다.

DENY 작업 및 operation.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 예제에서 ["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