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

서비스 메시 2.5는 Istio 1.18을 기반으로 하며 새로운 기능 및 제품 개선 사항을 제공합니다. Red Hat OpenShift Service Mesh는 많은 Istio 1.18 기능을 지원하지만 다음 예외 사항은 다음과 같습니다.

이번 릴리스에서는 다중 테넌트 메시에서 클러스터 전체 메시로 마이그레이션하기 위한 문서가 추가되었습니다. 자세한 내용은 다음 설명서를 참조하십시오.

이번 릴리스에서는 ARM 기반 클러스터의 Red Hat OpenShift Service Mesh Operator가 일반적으로 사용 가능한 기능으로 제공됩니다.

이 릴리스에서는 추적 확장 공급자의 일반적으로 사용 가능한 통합이 도입되었습니다. 이름이 지정된 요소 및 zipkin 공급자를 spec.meshConfig.extensionProviders 사양에 추가하여 Red Hat OpenShift distributed tracing platform(Tempo) 스택에 추적 데이터를 노출할 수 있습니다. 그런 다음 Telemetry 사용자 정의 리소스는 추적 범위를 수집하여 Tempo 배포자 서비스 엔드포인트로 전송하도록 Istio 프록시를 구성합니다.

이번 릴리스에서는 일반적으로 사용 가능한 OpenShift Service Mesh Console(OSSMC) 플러그인이 도입되었습니다.

OSSMC 플러그인은 서비스 메시에 대한 가시성을 제공하는 OpenShift 콘솔의 확장입니다. OSSMC 플러그인이 설치된 경우 새 Service Mesh 메뉴 옵션은 웹 콘솔의 탐색 창과 기존 워크로드 및 서비스 콘솔 페이지를 개선하는 새 서비스 메시 탭에서 사용할 수 있습니다.

OSSMC 플러그인의 기능은 독립 실행형 Kiali 콘솔의 기능과 매우 유사합니다. OSSMC 플러그인은 Kiali 콘솔을 대체하지 않으며 OSSMC 플러그인을 설치한 후에도 독립 실행형 Kiali 콘솔에 계속 액세스할 수 있습니다.

Istio OpenShift Routing (IOR)의 기본 설정이 변경되었습니다. 이번 릴리스에서는 ServiceMeshControlPlane 리소스의 새 인스턴스에 대해 자동 경로가 기본적으로 비활성화되어 있습니다.

ServiceMeshControlPlane 리소스의 새 인스턴스의 경우 ServiceMeshControlPlane 리소스의 gateways.openshiftRoute 사양에서 enabled 필드를 true 로 설정하여 자동 경로를 사용할 수 있습니다.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  gateways:
    openshiftRoute:
      enabled: true

ServiceMeshControlPlane 리소스의 기존 인스턴스를 Red Hat OpenShift Service Mesh 버전 2.5로 업데이트할 때 자동 경로는 기본적으로 활성화되어 있습니다.

networking.istio API의 concurrency 매개변수는 Istio 프록시가 실행되는 작업자 스레드 수를 구성합니다.

배포 간 일관성을 위해 이제 Istio는 프록시 컨테이너에 할당된 CPU 제한에 따라 동시성 매개변수를 구성합니다. 예를 들어, 2500m의 제한은 concurrency 매개변수를 3 으로 설정합니다. concurrency 매개변수를 다른 값으로 설정하면 Istio는 해당 값을 사용하여 CPU 제한을 사용하는 대신 프록시가 실행되는 스레드 수를 구성합니다.

이전에는 매개변수의 기본 설정은 2 입니다.

이제 Gateway API CRD(사용자 정의 리소스 정의)의 새 버전을 사용할 수 있습니다. 사용 중인 OpenShift Service Mesh 버전으로 설치해야 하는 게이트웨이 API 버전을 확인하려면 다음 표를 참조하십시오.

이번 릴리스에서는 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 콘솔의 기술 프리뷰 버전이 도입되었습니다. 자세한 내용은 OpenShift Service Mesh 콘솔 소개 (기술 프리뷰)를 참조하십시오.

이번 릴리스에서는 클러스터 전체 배포가 기술 프리뷰 기능으로 도입되었습니다. 클러스터 전체 배포에는 전체 클러스터의 리소스를 모니터링하는 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 Route 리소스에 복사합니다.

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

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

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

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

이번 릴리스에서는 모든 플랫폼의 Service Mesh 1.1을 기반으로 Service Mesh Control Plane에 대한 지원이 종료됩니다.

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

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

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

$ 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(ROSA), Azure Red Hat OpenShift(ARO) 또는 OpenShift Dedicated(OSD)의 Red Hat OpenShift Service의 클러스터 간에는 지원되지 않습니다.

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를 사용하여 자체 플러그인을 빌드할 수 있지만 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 경로에 조각이 있는 HTTP 요청(# 문자로 시작하는 섹션)은 Istio URI 경로 기반 권한 부여 정책을 우회할 수 있습니다. 예를 들어 Istio 권한 부여 정책은 URI 경로 /user/profile 으로 전송된 요청을 거부합니다. 취약한 버전에서 URI 경로 /user/profile#section1 을 포함하는 요청은 거부 정책 및 경로(정규화된 URI path /user/profile%23section1사용)를 우회하여 보안 문제로 이어질 수 있습니다.

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

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

완화 방법의 새로운 동작에서 옵트아웃하려면 URI의 조각 섹션이 유지됩니다. 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