검색

2.23. 3scale WebAssembly 모듈 사용

download PDF
참고

3scale-wasm-auth 모듈은 Red Hat OpenShift Service Mesh 2.1.0 이상과 3scale API Management 2.11 이상에서 실행됩니다.

3scale-wasm-auth 모듈은ABI(애플리케이션 바이너리 인터페이스)로 알려진 일련의 인터페이스를 사용하는 WebAssembly 모듈입니다. 이는 ABI를 구현하는 모든 소프트웨어를 구동하기 위해 Proxy-WASM 사양에 의해 정의되므로 3scale에 대한 HTTP 요청을 승인할 수 있습니다.

ABI 사양으로 Proxy-WASM은 host 라는 소프트웨어와 다른 이름이 지정된 모듈,프로그램 또는 확장 간의 상호 작용을 정의합니다. 호스트는 모듈에서 작업을 수행하는 데 사용하는 서비스 세트를 노출합니다. 이 경우 프록시 요청을 처리합니다.

호스트 환경은 소프트웨어와 상호 작용하는 WebAssembly 가상 머신(이 경우 HTTP 프록시)으로 구성됩니다.

모듈 자체는 가상 머신과 Proxy-WASM에 지정된 ABI에서 실행되는 지침을 제외하고 외부 세계와 별도로 실행됩니다. 이는 확장 지점을 소프트웨어를 제공하는 안전한 방법입니다. 확장 기능은 가상 머신 및 호스트와 잘 정의된 방식으로만 상호 작용할 수 있습니다. 상호 작용은 컴퓨팅 모델과 프록시가 있어야 하는 외부 세계와의 연결을 제공합니다.

2.23.1. 호환성

3scale-wasm-auth 모듈은 Proxy-WASM ABI 사양의 모든 구현과 완벽하게 호환되도록 설계되었습니다. 그러나 이 시점에서 Envoy 역방향 프록시로 작업하는 경우에만 철저하게 테스트되었습니다.

2.23.2. 독립 실행형 모듈로 사용

자체 포함 설계로 인해 서비스 메시와 독립적으로 Proxy-WASM 프록시와 3scale Istio 어댑터 배포로 작동하도록 이 모듈을 구성할 수 있습니다.

2.23.3. 사전 요구 사항

  • 이 모듈은 3scale 2.11 이상이 필요한 OpenID connect(OIDC) 를 사용하도록 서비스를 구성할 때를 제외하고 지원되는 모든 3scale 릴리스에서 작동합니다.

2.23.4. threescale-wasm-auth 모듈 구성

OpenShift Container Platform의 클러스터 관리자는 3scale-wasm-auth 모듈을 구성하여 ABI(애플리케이션 바이너리 인터페이스)를 통해 3scale API Management에 HTTP 요청을 승인할 수 있습니다. ABI는 호스트와 모듈 간의 상호 작용을 정의하고 호스트 서비스를 노출하며 모듈을 사용하여 프록시 요청을 처리할 수 있습니다.

2.23.4.1. WasmPlugin API 확장

서비스 메시는 WasmPlugin 이라는 사이드카 프록시에 Proxy-WASM 확장을 지정하고 적용하는 사용자 정의 리소스 정의를 제공합니다. 서비스 메시는 이 사용자 정의 리소스를 3scale로 HTTP API 관리가 필요한 워크로드 세트에 적용합니다.

자세한 내용은 사용자 정의 리소스 정의를 참조하십시오.

참고

WebAssembly 확장 구성은 현재 수동 프로세스입니다. 3scale 시스템에서 서비스 구성 가져오기 지원은 향후 릴리스에서 사용할 수 있습니다.

사전 요구 사항

  • 이 모듈을 적용할 서비스 메시 배포에서 Kubernetes 워크로드 및 네임스페이스를 식별합니다.
  • 3scale 테넌트 계정이 있어야 합니다. 일치하는 서비스와 관련 애플리케이션 및 메트릭이 정의된 SaaS 또는 3scale 2.11 온-프레미스 를 참조하십시오.
  • info 네임스페이스의 < product_page&gt; 마이크로 서비스에 모듈을 적용하는 경우 Bookinfo 샘플 애플리케이션을 참조하십시오.

    • 다음 예제는 threescale-wasm-auth 모듈에 대한 사용자 정의 리소스의 YAML 형식입니다. 이 예에서는 Service Mesh의 업스트림 Maistra 버전 WasmPlugin API를 나타냅니다. 모듈이 적용될 애플리케이션 세트를 식별하는 selector와 함께 threescale-wasm-auth 모듈이 배포되는 네임스페이스를 선언해야 합니다.

      apiVersion: extensions.istio.io/v1alpha1
      kind: WasmPlugin
      metadata:
        name: <threescale_wasm_plugin_name>
        namespace: <info> 1
      spec:
        selector: 2
          labels:
            app: <product_page>
        pluginConfig: <yaml_configuration>
        url: oci://registry.redhat.io/3scale-amp2/3scale-auth-wasm-rhel8:0.0.3
        phase: AUTHZ
        priority: 100
      1
      namespace 입니다.
      2
      selector 입니다.
  • spec.pluginConfig 필드는 모듈 구성에 따라 다르며 이전 예제에서는 채워지지 않습니다. 대신 이 예제에서는 <yaml_configuration> 자리 표시자 값을 사용합니다. 이 사용자 정의 리소스 예의 형식을 사용할 수 있습니다.

    • spec.pluginConfig 필드는 애플리케이션에 따라 다릅니다. 기타 모든 필드는 이 사용자 정의 리소스의 여러 인스턴스에서 유지됩니다. 예를 들면 다음과 같습니다.

      • URL: 최신 버전의 모듈이 배포된 경우에만 변경됩니다.
      • phase: 프록시가 OIDC(OpenID Connect) 토큰 검증과 같은 로컬 인증을 수행한 후 이 모듈을 호출해야 하므로 동일하게 유지됩니다.
  • spec.pluginConfig 및 나머지 사용자 정의 리소스에 모듈 구성이 있으면 oc apply 명령을 사용하여 적용합니다.

    $ oc apply -f threescale-wasm-auth-info.yaml

2.23.5. 3scale 외부 ServiceEntry 오브젝트 적용

3scale-wasm-auth 모듈이 3scale에 대한 요청을 승인하도록 하려면 모듈에서 3scale 서비스에 액세스할 수 있어야 합니다. HTTPS 프로토콜을 사용하도록 외부 ServiceEntry 오브젝트 및 해당 DestinationRule 오브젝트를 적용하여 Red Hat OpenShift Service Mesh 내에서 이 작업을 수행할 수 있습니다.

CR(사용자 정의 리소스)은 Service Management API 및 계정 관리 API의 백엔드 및 시스템 구성 요소에 대해 서비스 메시 내에서 3scale Hosted(SaaS)로 보안 액세스를 위한 서비스 항목 및 대상 규칙을 설정합니다. Service Management API는 각 요청의 권한 부여 상태에 대한 쿼리를 수신합니다. 계정 관리 API는 서비스에 대한 API 관리 구성 설정을 제공합니다.

프로세스

  1. 3scale Hosted 백엔드 의 다음 외부 ServiceEntry CR 및 관련 DestinationRule CR을 클러스터에 적용합니다.

    1. ServiceEntry CR을 service-entry-threescale-saas-backend.yml 이라는 파일에 추가합니다.

      ServiceEntry CR

      apiVersion: networking.istio.io/v1beta1
      kind: ServiceEntry
      metadata:
        name: service-entry-threescale-saas-backend
      spec:
        hosts:
        - su1.3scale.net
        ports:
        - number: 443
          name: https
          protocol: HTTPS
        location: MESH_EXTERNAL
        resolution: DNS

    2. destination-rule-threescale-saas-backend.yml 이라는 파일에 DestinationRule CR을 추가합니다.

      DestinationRule CR

      apiVersion: networking.istio.io/v1beta1
      kind: DestinationRule
      metadata:
        name: destination-rule-threescale-saas-backend
      spec:
        host: su1.3scale.net
        trafficPolicy:
          tls:
            mode: SIMPLE
            sni: su1.3scale.net

    3. 다음 명령을 실행하여 3scale Hosted 백엔드의 외부 ServiceEntry CR을 클러스터에 적용하고 저장합니다.

      $ oc apply -f service-entry-threescale-saas-backend.yml
    4. 다음 명령을 실행하여 3scale Hosted 백엔드의 외부 DestinationRule CR을 클러스터에 적용하고 저장합니다.

      $ oc apply -f destination-rule-threescale-saas-backend.yml
  2. 3scale Hosted 시스템의 다음 외부 ServiceEntry CR 및 관련 DestinationRule CR을 클러스터에 적용합니다.

    1. ServiceEntry CR을 service-entry-threescale-saas-system.yml 이라는 파일에 추가합니다.

      ServiceEntry CR

      apiVersion: networking.istio.io/v1beta1
      kind: ServiceEntry
      metadata:
        name: service-entry-threescale-saas-system
      spec:
        hosts:
        - multitenant.3scale.net
        ports:
        - number: 443
          name: https
          protocol: HTTPS
        location: MESH_EXTERNAL
        resolution: DNS

    2. destination-rule-threescale-saas-system.yml 이라는 파일에 DestinationRule CR을 추가합니다.

      DestinationRule CR

      apiVersion: networking.istio.io/v1beta1
      kind: DestinationRule
      metadata:
        name: destination-rule-threescale-saas-system
      spec:
        host: multitenant.3scale.net
        trafficPolicy:
          tls:
            mode: SIMPLE
            sni: multitenant.3scale.net

    3. 다음 명령을 실행하여 3scale Hosted 시스템의 외부 ServiceEntry CR을 클러스터에 적용하고 저장합니다.

      $ oc apply -f service-entry-threescale-saas-system.yml
    4. 다음 명령을 실행하여 3scale Hosted 시스템의 외부 DestinationRule CR을 클러스터에 적용하고 저장합니다.

      $ oc apply -f <destination-rule-threescale-saas-system.yml>

또는 in-mesh 3scale 서비스를 배포할 수 있습니다. in-mesh 3scale 서비스를 배포하려면 3scale을 배포하고 배포에 연결하여 CR에서 서비스의 위치를 변경합니다.

2.23.6. 3scale WebAssembly 모듈 구성

WasmPlugin 사용자 정의 리소스 사양은 Proxy-WASM 모듈에서 읽을 수 있는 구성을 제공합니다.

사양은 호스트에 포함되어 Proxy-WASM 모듈에서 읽습니다. 일반적으로 이 구성은 모듈에서 구문 분석할 JSON 파일 형식에 있지만 WasmPlugin 리소스는 사양 값을 YAML로 해석하고 모듈의 사용을 위해 JSON으로 변환할 수 있습니다.

독립 실행형 모드에서 Proxy-WASM 모듈을 사용하는 경우 JSON 형식을 사용하여 구성을 작성해야 합니다. JSON 형식을 사용하면 host 구성 파일(예: Envoy ) 내에서 이스케이프 및 인용을 사용하는 것을 의미합니다. WasmPlugin 리소스와 함께 WebAssembly 모듈을 사용하는 경우 구성은 YAML 형식으로 되어 있습니다. 이 경우 잘못된 구성은 모듈이 사이드카의 로깅 스트림에 대한 JSON 표현을 기반으로 진단을 표시하도록 강제 적용합니다.

중요

EnvoyFilter 사용자 정의 리소스는 지원되는 API가 아니지만 일부 3scale Istio 어댑터 또는 Service Mesh 릴리스에서 사용할 수 있습니다. EnvoyFilter 사용자 정의 리소스를 사용하는 것은 권장되지 않습니다. EnvoyFilter 사용자 정의 리소스 대신 WasmPlugin API를 사용합니다. EnvoyFilter 사용자 정의 리소스를 사용해야 하는 경우 사양을 JSON 형식으로 지정해야 합니다.

2.23.6.1. 3scale WebAssembly 모듈 구성

3scale WebAssembly 모듈 구성의 아키텍처는 3scale 계정 및 권한 부여 서비스 및 처리할 서비스 목록에 따라 다릅니다.

사전 요구 사항

사전 요구 사항은 모든 경우에서 최소 필수 필드 세트입니다.

  • 3scale 계정 및 권한 부여 서비스의 경우 backend-listener URL입니다.
  • 처리할 서비스 목록: 서비스 ID와 하나 이상의 인증 정보에서 방법 및 찾을 위치를 찾습니다.
  • userkey, appidappkey 및 OpenID Connect(OIDC) 패턴을 처리하는 예를 찾을 수 있습니다.
  • WebAssembly 모듈은 정적 구성에 지정한 설정을 사용합니다. 예를 들어, 모듈에 매핑 규칙 구성을 추가하는 경우 3scale 관리 포털에 이러한 매핑 규칙이 없는 경우에도 항상 적용됩니다. 나머지 WasmPlugin 리소스는 spec.pluginConfig YAML 항목에 있습니다.

2.23.6.2. 3scale WebAssembly 모듈 api 오브젝트

3scale WebAssembly 모듈의 api 최상위 문자열은 모듈에서 사용할 구성 버전을 정의합니다.

참고

api 오브젝트의 존재하지 않거나 지원되지 않는 버전은 3scale WebAssembly 모듈을 작동하지 않게 렌더링합니다.

api 최상위 수준 문자열 예

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
  namespace: <info>
spec:
  pluginConfig:
    api: v1
# ...

api 항목은 구성에 대한 나머지 값을 정의합니다. 유일하게 허용되는 값은 v1 입니다. 현재 구성과의 호환성을 중단하거나 v1 을 사용하는 모듈에서 처리할 수 없는 논리가 필요한 새 설정에는 다른 값이 필요합니다.

2.23.6.3. 3scale WebAssembly 모듈 시스템 오브젝트

system 최상위 오브젝트는 특정 계정에 대한 3scale 계정 관리 API에 액세스하는 방법을 지정합니다. upstream 필드는 오브젝트에서 가장 중요한 부분입니다. system 오브젝트는 선택 사항이지만 3scale의 시스템 구성 요소에 대한 연결을 제공하지 않으려면 3scale WebAssembly 모듈에 완전히 정적 구성을 제공하지 않는 것이 좋습니다.

system 오브젝트 외에 정적 구성 오브젝트를 제공하는 경우 정적 개체가 항상 우선합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
    system:
      name: <saas_porta>
      upstream: <object>
      token: <my_account_token>
      ttl: 300
# ...
표 2.22. system 오브젝트 필드
이름설명필수 항목

name

현재 다른 위치에서 참조되지 않은 3scale 서비스의 식별자입니다.

선택 사항

upstream

연결할 네트워크 호스트에 대한 세부 정보입니다. upstream 은 시스템이라는 3scale 계정 관리 API 호스트를 나타냅니다.

제공됨

token

읽기 권한이 있는 3scale 개인 액세스 토큰입니다.

제공됨

ttl

새 변경 사항을 가져오기 전에 이 호스트에서 검색된 구성을 유효한 것으로 간주하는 최소 시간(초)입니다. 기본값은 600초(10분)입니다. 참고: 최대 크기는 없지만 모듈은 이 TTL이 경과한 후 적절한 시간 내에 구성을 가져옵니다.

선택 사항

2.23.6.4. 3scale WebAssembly 모듈 업스트림 오브젝트

upstream 오브젝트는 프록시가 호출을 수행할 수 있는 외부 호스트를 설명합니다.

apiVersion: maistra.io/v1
upstream:
  name: outbound|443||multitenant.3scale.net
  url: "https://myaccount-admin.3scale.net/"
  timeout: 5000
# ...
표 2.23. upstream 오브젝트 필드
이름설명필수 항목

name

name은 자유 형식의 식별자가 아닙니다. 프록시 구성에 정의된 외부 호스트의 식별자입니다. 독립형 Envoy 구성의 경우 다른 프록시에서 upstream 이라고도 하는 클러스터 이름으로 매핑됩니다. 참고: Service Mesh 및 3scale Istio 어댑터 컨트롤 플레인에서 이 필드의 값은 세로 막대(|)를 여러 필드의 구분 기호로 사용하는 형식에 따라 이름을 구성하므로 이 필드의 값입니다. 이 통합의 목적을 위해 항상 outbound|<port>||<hostname> 형식을 사용합니다.

제공됨

url

설명된 서비스에 액세스하기 위한 전체 URL입니다. 스키마에 의해 제한되지 않는 한 TCP 포트를 포함해야 합니다.

제공됨

Timeout

응답 시간을 초과하여 이 서비스에 대한 연결이 오류로 간주되도록 시간 제한 시간(밀리초)입니다. 기본값은 1000초입니다.

선택 사항

2.23.6.5. 3scale WebAssembly 모듈 백엔드 오브젝트

backend 최상위 오브젝트는 HTTP 요청을 승인하고 보고하기 위해 3scale Service Management API에 액세스하는 방법을 지정합니다. 이 서비스는 3scale의 백엔드 구성 요소에서 제공합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
# ...
    backend:
      name: backend
      upstream: <object>
# ...
표 2.24. backend 오브젝트 필드
이름설명필수 항목

name

현재 다른 위치에서 참조되지 않은 3scale 백엔드의 식별자입니다.

선택 사항

upstream

연결할 네트워크 호스트에 대한 세부 정보입니다. 이는 알려진 3scale 계정 관리 API 호스트, 시스템을 참조해야 합니다.

제공됨 가장 중요하고 필요한 필드입니다.

2.23.6.6. 3scale WebAssembly 모듈 서비스 오브젝트

services 최상위 오브젝트는 module의 이 특정 인스턴스에서 처리하는 서비스 ID를 지정합니다.

계정에는 여러 서비스가 있으므로 처리할 서비스를 지정해야 합니다. 나머지 구성에서는 서비스 구성 방법에 따라 달라집니다.

services 필드는 필수입니다. 유용한 서비스를 하나 이상 포함해야 하는 배열입니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
# ...
    services:
    - id: "2555417834789"
      token: service_token
      authorities:
        - "*.app"
        - 0.0.0.0
        - "0.0.0.0:8443"
      credentials: <object>
      mapping_rules: <object>
# ...

services 배열의 각 요소는 3scale 서비스를 나타냅니다.

표 2.25. services 오브젝트 필드
이름설명필수 항목

ID

현재 다른 위치에서 참조되지 않은 이 3scale 서비스의 식별자입니다.

제공됨

token

token은 시스템에서 서비스에 대한 프록시 구성에서 있거나 다음 curl 명령을 사용하여 시스템에서 검색할 수 있습니다.

curl https://<system_host>/admin/api/services/<service_id>/proxy/configs/production/latest.json?access_token=<access_token>" | jq '.proxy_config.content.backend_authentication_value

선택 사항

기관

일치하는 URL권한을 나타내는 문자열 배열입니다. 이러한 문자열은 별표(*), 더하기 기호(+) 및 물음표(?)를 지원하는 글러 패턴을 허용합니다.

제공됨

credentials

찾을 자격 증명 종류와 위치를 정의하는 오브젝트입니다.

제공됨

mapping_rules

매핑 규칙 및 3scale 메서드를 나타내는 오브젝트 배열입니다.

선택 사항

2.23.6.7. 3scale WebAssembly 모듈 인증 정보 오브젝트

credentials 오브젝트는 service 오브젝트의 구성 요소입니다. credentials 는 조회할 인증 정보와 이 작업을 수행하는 단계를 지정합니다.

모든 필드는 선택 사항이지만 하나 이상의 user_key 또는 app_id 를 지정해야 합니다. 각 인증 정보를 지정하는 순서는 모듈에 의해 미리 설정되므로 관련이 없습니다. 각 인증 정보 인스턴스 하나만 지정합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
# ...
    services:
    - credentials:
        user_key: <array_of_lookup_queries>
        app_id: <array_of_lookup_queries>
        app_key: <array_of_lookup_queries>
# ...
표 2.26. credentials 오브젝트 필드
이름설명필수 항목

user_key

3scale 사용자 키를 정의하는 조회 쿼리의 배열입니다. 사용자 키는 일반적으로 API 키라고 합니다.

선택 사항

app_id

3scale 애플리케이션 ID를 정의하는 조회 쿼리의 배열입니다. 애플리케이션 ID는 3scale에서 제공하거나 Red Hat Single Sign-On(RH-SS0) 또는 OpenID Connect(OIDC)와 같은 ID 공급자를 사용하여 제공합니다. 여기에 지정된 조회 쿼리의 해상도가 성공하고 두 개의 값으로 확인되면 app_idapp_key 를 설정합니다.

선택 사항

app_key

3scale 애플리케이션 키를 정의하는 조회 쿼리의 배열입니다. 확인된 app_id 가 없는 애플리케이션 키는 쓸모 없으므로 app_id 가 지정된 경우에만 이 필드를 지정합니다.

선택 사항

2.23.6.8. 3scale WebAssembly 모듈 조회 쿼리

lookup query 오브젝트는 credentials 오브젝트의 필드 중 하나에 포함됩니다. 지정된 인증 정보 필드를 찾아서 처리하는 방법을 지정합니다. 평가되면 성공적인 해결 방법은 하나 이상의 값이 발견되었음을 의미합니다. 실패한 해결 방법은 값을 찾을 수 없음을 의미합니다.

lookup queries 의 배열은 단락 또는 관계를 설명합니다. 쿼리 중 하나를 성공적으로 해결하면 나머지 쿼리의 평가를 중지하고 값 또는 값을 지정된 인증 정보 유형에 할당합니다. 배열의 각 쿼리는 서로 독립적입니다.

lookup query 는 여러 소스 유형 중 하나일 수 있는 소스 오브젝트인 단일 필드로 구성됩니다. 다음 예제를 참조하십시오.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
# ...
    services:
    - credentials:
        user_key:
          - <source_type>: <object>
          - <source_type>: <object>
# ...
        app_id:
          - <source_type>: <object>
# ...
        app_key:
          - <source_type>: <object>
# ...

2.23.6.9. 3scale WebAssembly 모듈 소스 오브젝트

source 오브젝트는 credentials 오브젝트 필드 내에 있는 소스 배열의 일부로 존재합니다. source-type이라고 하는 오브젝트 필드 이름은 다음 중 하나입니다.

  • header: 조회 쿼리는 HTTP 요청 헤더를 입력으로 수신합니다.
  • QUERY_STRING: lookup query 는 URL 쿼리 문자열 매개변수를 입력으로 수신합니다.
  • filter: lookup query 는 필터 메타데이터를 입력으로 수신합니다.

모든 source-type 오브젝트에는 다음 두 필드가 있습니다.

표 2.27. source-type 오브젝트 필드
이름설명필수 항목

keys

각 문자열 배열은 입력 데이터에 있는 항목을 참조하는 key 입니다.

제공됨

Ops

key 항목을 일치시키는 operations 배열입니다. 배열은 작업에서 입력을 수신하고 다음 작업에서 출력을 생성하는 파이프라인입니다. 출력을 제공에 실패한 operationlookup query를 실패한 것으로 확인합니다. 작업의 파이프라인 순서에 따라 평가 순서가 결정됩니다.

선택 사항

filter 필드 이름에는 데이터를 조회하는 데 사용하는 메타데이터의 경로를 표시하는 데 필요한 path 항목이 있습니다.

key 입력 데이터와 일치하면 나머지 키가 평가되지 않고 소스 확인 알고리즘이 지정된 operations (ops)을 실행하도록 건너뜁니다. ops 를 지정하지 않으면 일치하는 key 의 결과 값이 반환됩니다.

Operations은 첫 번째 단계에서 key를 조회한 후 입력에 대한 특정 조건 및 변환을 지정하는 방법을 제공합니다. 속성을 변환, 디코딩 및 증명해야 할 때 operations을 사용하지만 모든 요구 사항과 Turing-completeness 가 부족한 성숙한 언어를 제공하지는 않습니다.

스택은 operations 출력을 저장했습니다. 평가되면 인증 정보가 사용하는 값 수에 따라 스택 하단에 값 또는 값을 할당하여 lookup query 가 완료됩니다.

2.23.6.10. 3scale WebAssembly 모듈 작업 오브젝트

특정 source type에 속하는 ops 배열의 각 요소는 값에 변환을 적용하거나 테스트를 수행하는 operation 오브젝트입니다. 이러한 오브젝트에 사용할 필드 이름은 operation 자체의 이름이며 모든 값 operation에 대한 매개변수입니다. 이는 필드 및 값이 포함된 매핑, 목록 또는 문자열과 같은 구조 개체일 수 있습니다.

대부분의 operation은 하나 이상의 입력에 참여하고 하나 이상의 출력을 생성합니다. 입력을 사용하거나 출력을 생성할 때 해당 스택은 값 스택에서 작동합니다. 작업에서 사용하는 각 값은 값 스택에서 채워지고 처음에 모든 source 일치 항목으로 채워집니다. 해당 리소스에서 출력한 값은 스택으로 푸시됩니다. 다른 operations에서는 특정 속성을 나타내는 것 이외의 출력을 사용하거나 생성하지 않지만 값 스택을 검사합니다.

참고

확인이 완료되면 다음 단계에서 선택한 값(예: app_id,app_key 또는 user_key )은 스택의 하단 값에서 가져옵니다.

다음과 같은 몇 가지 operations 범주가 있습니다.

  • decode: 이러한 변환은 다른 형식을 가져오도록 디코딩하여 입력 값을 변환합니다.
  • string: 문자열 값을 입력으로 사용하고 변환 및 검사를 수행합니다.
  • stack: 입력에서 값 집합을 가져와서 스택의 특정 위치를 여러 스택 변환 및 선택합니다.
  • check: 이러한 어설션 속성은 부작용없는 방식으로 작업 세트에 대한 속성입니다.
  • Control: 평가 흐름을 수정할 수 있는 작업을 수행합니다.
  • format: 입력 값의 형식별 구조를 구문 분석하고 해당 값의 값을 조회합니다.

모든 작업은 이름 식별자에 의해 문자열로 지정됩니다.

추가 리소스

2.23.6.11. 3scale WebAssembly 모듈 mapping_rules 오브젝트

mapping_rules 오브젝트는 service 오브젝트의 일부입니다. REST 경로 패턴 및 관련 3scale 메트릭 세트를 지정하고 패턴이 일치할 때 사용할 증가 수를 지정합니다.

system 최상위 오브젝트에 동적 구성이 제공되지 않은 경우 값이 필요합니다. 오브젝트가 system 최상위 항목 외에 제공되는 경우 mapping_rules 오브젝트가 먼저 평가됩니다.

mapping_rules 는 배열 오브젝트입니다. 해당 배열의 각 요소는 mapping_rule 개체입니다. 들어오는 요청에 대한 평가 일치 매핑 규칙은 APIManager 에게 권한 부여 및 보고를 위한 3scale methods 세트를 제공합니다. 여러 일치 규칙이 동일한 methods 를 참조하는 경우 3scale로 호출할 때 deltas 의 합계가 요약됩니다. 예를 들어, 두 개의 규칙이 deltas 1과 3을 사용하여 Hits 메서드를 두 번 늘리면 3scale에 보고하는 Hits의 단일 메서드 항목의 delta는 4입니다.

2.23.6.12. 3scale WebAssembly 모듈 mapping_rule 오브젝트

mapping_rule 오브젝트는 mapping_rules 오브젝트의 배열의 일부입니다.

mapping_rule 오브젝트 필드는 다음 정보를 지정합니다.

  • 일치시킬 HTTP 요청 방법입니다.
  • 경로와 일치하는 패턴입니다.
  • 보고할 양과 함께 보고하는 3scale 방법입니다. 필드를 지정하는 순서에 따라 평가 순서가 결정됩니다.
표 2.28. mapping_rule 오브젝트 필드
이름설명필수 항목

method

동사라고도 하는 HTTP 요청 메서드를 나타내는 문자열을 지정합니다. 허용되는 값은 허용되는 HTTP 메서드 이름 중 하나와 대소문자를 구분하지 않습니다. 특수 값은 모든 메서드와 일치합니다.

제공됨

패턴

HTTP 요청의 URI 경로 구성 요소와 일치하는 패턴입니다. 이 패턴은 3scale에서 설명한 것과 동일한 구문을 따릅니다. {this} 와 같은 중괄호 사이의 문자 시퀀스를 사용하여 와일드카드 (*) 문자를 사용할 수 있습니다.

제공됨

usages

usage 오브젝트 목록입니다. 규칙이 일치하면 deltas와 함께 모든 방법이 승인 및 보고를 위해 3scale로 전송되는 방법 목록에 추가됩니다.

다음 필수 필드를 사용하여 usages 오브젝트를 삽입합니다.

  • name: 보고할 method 시스템 이름입니다.
  • delta: 해당 method를 얼마나 늘릴 수 있는지에 대한 것입니다.

제공됨

last

이 규칙의 성공적인 일치 여부를 통해 더 많은 매핑 규칙 평가를 중지해야 하는지 여부입니다.

선택적 부울입니다. 기본값은 false입니다.

다음 예제는 3scale의 메서드 간 기존 계층 구조와 독립적입니다. 즉 3scale 측에서 실행되는 모든 것은 이에 영향을 미치지 않습니다. 예를 들어 Hits 지표는 모두 상위일 수 있으므로 권한 있는 요청에서 보고된 모든 메서드 합계로 인해 4 조회를 저장하고 3scale Authrep API 엔드포인트를 호출합니다.

아래 예제에서는 모든 규칙과 일치하는 경로 /products/1/sold 에 대한 GET 요청을 사용합니다.

mapping_rules GET 요청 예

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  pluginConfig:
# ...
    mapping_rules:
      - method: GET
        pattern: /
        usages:
          - name: hits
            delta: 1
      - method: GET
        pattern: /products/
        usages:
          - name: products
            delta: 1
      - method: ANY
        pattern: /products/{id}/sold
        usages:
          - name: sales
            delta: 1
          - name: products
            delta: 1
# ...

모든 usages는 다음과 같이 사용 데이터를 사용하여 모듈이 3scale에 수행하는 요청에 추가됩니다.

  • 히트: 1
  • 제품: 2
  • 영업: 1

2.23.7. 인증 정보 사용 사례에 대한 3scale WebAssembly 모듈 예제

구성 단계를 적용하는 데 대부분의 시간을 할애하여 서비스에 대한 요청의 인증 정보를 가져옵니다.

다음은 특정 사용 사례에 맞게 조정하도록 수정할 수 있는 credentials 예제입니다.

자체 lookup queries 를 사용하여 여러 소스 오브젝트를 지정할 때 모두 결합할 수 있지만 둘 중 하나가 성공적으로 해결될 때까지 순서대로 평가됩니다.

2.23.7.1. 쿼리 문자열 매개변수의 API 키(user_key)

다음 예제에서는 쿼리 문자열 매개변수 또는 동일한 이름의 헤더에서 user_key 를 조회합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
# ...
    services:
# ...
      credentials:
        user_key:
          - query_string:
              keys:
                - <user_key>
          - header:
              keys:
                - <user_key>
# ...

2.23.7.2. 애플리케이션 ID 및 키

다음 예제에서는 쿼리 또는 헤더에서 app_keyapp_id 자격 증명을 조회합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
# ...
    services:
# ...
      credentials:
        app_id:
          - query_string:
              keys:
                - <app_id>
          - header:
              keys:
                - <app_id>
        app_key:
          - query_string:
              keys:
                - <app_key>
          - header:
              keys:
                - <app_key>
# ...

2.23.7.3. 인증 헤더

요청에는 authorization 헤더에 app_idapp_key 가 포함됩니다. 끝에 출력되는 하나 이상의 값이 있는 경우 app_key 를 할당할 수 있습니다.

해결 방법은 끝에 하나 또는 두 개의 출력이 있는 경우 app_key 를 할당합니다.

authorization 헤더는 권한 부여 유형이 포함된 값을 지정하고 해당 값은 Base64 로 인코딩됩니다. 즉, 값을 공백 문자로 분할하고 두 번째 출력을 가져온 다음 콜론(:)을 구분 기호로 사용하여 다시 분할할 수 있습니다. 예를 들어 app_id:app_key 형식을 사용하는 경우 헤더는 credential에 대한 다음 예와 유사합니다.

aladdin:opensesame:  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

다음 예와 같이 소문자 헤더 필드 이름을 사용해야 합니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
# ...
    services:
# ...
      credentials:
        app_id:
          - header:
              keys:
                - authorization
              ops:
                - split:
                    separator: " "
                    max: 2
                - length:
                    min: 2
                - drop:
                    head: 1
                - base64_urlsafe
                - split:
                    max: 2
        app_key:
          - header:
              keys:
                - app_key
# ...

이전 예제 사용 사례에서는 헤더에서 authorization을 확인합니다.

  1. 문자열 값을 사용하여 공백으로 분할하여 credential 유형 및 credential 자체의 두 개 이상의 값을 생성하는지 확인한 다음 credential -유형을 삭제합니다.
  2. 그런 다음 필요한 데이터를 포함하는 두 번째 값을 디코딩하고 콜론(:) 문자를 사용하여 첫 번째 app_id, app_key 를 포함한 작업 스택을 사용하여 분할합니다.

    1. 권한 부여 헤더에 app_key 가 없는 경우 특정 소스가 확인됩니다(예: 이 경우 키가 app_key 인 헤더입니다.
  3. credentials 정보에 추가 조건을 추가하려면 app_idaladdin 또는 admin 인 경우 Basic 권한 부여를 허용하거나 app_id 가 길이가 8자 이상입니다.
  4. app_key 는 다음 예와 같이 값을 포함해야 하며 최소 64자 이상이어야 합니다.

    apiVersion: extensions.istio.io/v1alpha1
    kind: WasmPlugin
    metadata:
      name: <threescale_wasm_plugin_name>
    spec:
    # ...
        services:
    # ...
          credentials:
            app_id:
              - header:
                  keys:
                    - authorization
                  ops:
                    - split:
                        separator: " "
                        max: 2
                    - length:
                        min: 2
                    - reverse
                    - glob:
                      - Basic
                    - drop:
                        tail: 1
                    - base64_urlsafe
                    - split:
                        max: 2
                     - test:
                        if:
                          length:
                            min: 2
                       then:
                          - strlen:
                              max: 63
                          - or:
                              - strlen:
                                  min: 1
                              - drop:
                                  tail: 1
                    - assert:
                      - and:
                        - reverse
                        - or:
                          - strlen:
                              min: 8
                          - glob:
                            - aladdin
                            - admin
    # ...
  5. authorization 헤더 값을 선택한 후 유형을 맨 위에 배치하도록 스택을 리버스하여 Basic credential-type이 제공됩니다.
  6. 그 위에 glob match를 실행합니다. 유효성을 검증하고 인증 정보가 디코딩되고 분할되면 스택 하단에서 app_id 를 가져오고 상단에 app_key 가 발생할 수 있습니다.
  7. test 실행: 스택에 두 개의 값이 있는 경우, 이는 app_key 를 인수했음을 의미합니다.

    1. app_idapp_key 를 포함하여 문자열 길이가 1에서 63 사이인지 확인합니다. 키 길이가 0인 경우 키를 삭제하고 키가 없는 것처럼 계속합니다. app_id 만 있고 app_key 가 없는 경우 누락된 다른 분기는 성공적인 테스트 및 평가가 계속됨을 나타냅니다.

마지막 작업인 assert 는 부작용을 스택에 추가하지 않음을 나타냅니다. 그런 다음 스택을 수정할 수 있습니다.

  1. 맨 위에 app_id 를 갖도록 스택을 리버스합니다.

    1. app_key 가 있는지 여부에 관계없이 스택을 리버스하면 app_id 가 맨 위에 있습니다.
  2. 테스트 전반에서 스택의 내용을 보존하려면 and 를 사용합니다.

    그런 다음 다음 옵션 중 하나를 사용합니다.

    • app_id 의 문자열 길이가 8인지 확인합니다.
    • app_idaladdin 또는 admin 과 일치하는지 확인합니다.

2.23.7.4. OpenID Connect (OIDC) 사용 사례

Service Mesh 및 3scale Istio 어댑터의 경우 다음 예에 표시된 대로 RequestAuthentication 을 배포하여 자체 워크로드 데이터 및 jwtRules 를 채워야 합니다.

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: info
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak
    jwksUri: >-
      http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs

RequestAuthentication 을 적용하면 JWT 토큰을 검증하기 위해 기본 플러그인 으로 Envoy 를 구성합니다. 프록시는 모듈을 실행하기 전에 모든 것을 검증하므로 실패하는 요청이 3scale WebAssembly 모듈로 만들지 않습니다.

JWT 토큰이 검증되면 프록시는 해당 콘텐츠를 내부 메타데이터 오브젝트에 저장하고, 해당 키는 플러그인의 특정 구성에 따라 달라지는 항목을 저장합니다. 이 사용 사례는 알 수 없는 키 이름을 포함하는 단일 항목을 사용하여 구조 오브젝트를 조회할 수 있는 기능을 제공합니다.

OIDC의 3scale app_id 는 OAuth client_id 와 일치합니다. 이는 JWT 토큰의 azp 또는 aud 필드에 있습니다.

Envoy의 기본 JWT 인증 필터에서 app_id 필드를 가져오려면 다음 예제를 참조하십시오.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
# ...
    services:
# ...
      credentials:
        app_id:
          - filter:
              path:
                - envoy.filters.http.jwt_authn
                - "0"
              keys:
                - azp
                - aud
              ops:
                - take:
                    head: 1
# ...

이 예제에서는 filter 소스 유형을 사용하여 Envoy-별 JWT 인증 네이티브 플러그인에서 오브젝트의 필터 메타데이터를 찾도록 모듈에 지시합니다. 이 플러그인에는 단일 항목이 있고 사전 구성된 이름이 있는 구조 오브젝트의 일부로 JWT 토큰이 포함됩니다. 단일 항목에만 액세스하도록 지정하려면 0 을 사용합니다.

결과 값은 다음 두 필드를 해결할 구조입니다.

  • azp: app_id 가 있는 값입니다.
  • AUD: 이 정보를 찾을 수 있는 값입니다.

이 작업을 수행하면 할당에 대해 하나의 값만 유지됩니다.

2.23.7.5. 헤더에서 JWT 토큰 가져오기

일부 설정에는 인증된 토큰이 JSON 형식의 헤더를 통해 이 모듈에 도달하는 JWT 토큰에 대한 검증 프로세스가 있을 수 있습니다.

app_id 를 가져오려면 다음 예제를 참조하십시오.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
# ...
    services:
# ...
      credentials:
        app_id:
          - header:
              keys:
                - x-jwt-payload
              ops:
                - base64_urlsafe
                - json:
                  - keys:
                    - azp
                    - aud
                - take:
                    head: 1
# ,,,

2.23.8. 3scale WebAssembly 모듈 최소 작업 구성

다음은 3scale WebAssembly 모듈의 최소 작업 구성 예입니다. 이 파일을 복사하여 붙여넣고 편집하여 고유한 구성으로 작업할 수 있습니다.

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: <threescale_wasm_plugin_name>
spec:
  url: oci://registry.redhat.io/3scale-amp2/3scale-auth-wasm-rhel8:0.0.3
  imagePullSecret: <optional_pull_secret_resource>
  phase: AUTHZ
  priority: 100
  selector:
    labels:
      app: <product_page>
  pluginConfig:
    api: v1
    system:
      name: <system_name>
      upstream:
        name: outbound|443||multitenant.3scale.net
        url: https://istiodevel-admin.3scale.net/
        timeout: 5000
      token: <token>
    backend:
      name: <backend_name>
      upstream:
        name: outbound|443||su1.3scale.net
        url: https://su1.3scale.net/
        timeout: 5000
      extensions:
      - no_body
    services:
    - id: '2555417834780'
      authorities:
      - "*"
      credentials:
        user_key:
          - query_string:
              keys:
                - <user_key>
          - header:
              keys:
                - <user_key>
        app_id:
          - query_string:
              keys:
                - <app_id>
          - header:
              keys:
                - <app_id>
        app_key:
          - query_string:
              keys:
                - <app_key>
          - header:
              keys:
                - <app_key>
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.