Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-9998

Provided token not validated and any token with any permission can be added to the config

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Cannot Reproduce
    • Icon: Major Major
    • None
    • None
    • Istio Integration
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started

      Sharing what has been asked by the customer here:

      I was trying to follow this https://redhat-solution-patterns.github.io/solution-pattern-apim-servicemesh/comprehensive-service-architecture/index.html article to understand, how we can using 3Scale for API management with Istio.

      In this article they have demonstrated with an example demo - https://redhat-solution-patterns.github.io/solution-pattern-apim-servicemesh/comprehensive-service-architecture/03-demo.html

      I have followed the demo and deployed this demo using the ansible playbook which deploys all the required components 3Scale etc and at the end it deploys WasmPlugin CR and with right 3Scale admin token all the internal service to service communication is secured.

      pluginConfig:
      api: v1
      system:
      name: system
      token: replace with access token

      But I wanted to use token with only read only permission and not admin token but was failing to verify it because no mater what value I provide as a token all communication remain successful (as showed in the kiali Graph)

      My question here is whats the right way to debug WasmPlugin using WasmPlugin CR. How and where to look for logs if the CR got processed without an error and specifically how can I verify if token provided is working fine to authenticate requests using 3Scale APIs.

      Define the value or impact to you or the business
      One of our customer wants to use Istio Gateway integration 3Scale using WasmPlugin but in the redhat article its using 3Scale's admin token and we're trying to run the same demo using 3Scale's read only token but failing to identify how debug if istio is able to interact with 3Scale using any other token then admin token.

      We're expecting that if we provide any invalid 3Scale token in WasmPlugin CR then Envoy proxy will throw some error which we would be able to verify in application's istio proxy sidecar logs but we failed to figure out to see any 3Scale's response response or any log msg from envoy filter.

      Help is required to guide the customer where to debug this in ServiceMesh & the WASM plugin.

      Additional information shared:

      Even providing the admin token and service token in WasmPlugin CR, it always throws this error msg in log

      
      2023-07-27T19:42:30.904787Z warning envoy wasm wasm log: (root/1) 1420001495: Fetching config failed for service 3, error config fetching failed
      
      pluginConfig:
         api: v1
         system:
           name: system
           token: ZcVhx------- # 3Scale Admin token
           upstream:
             name: >-
               outbound|3000||system-provider.3scale.svc.cluster.local
             timeout: 5000
             url: 'http://system-provider.3scale.svc.cluster.local'
         backend:
           extensions:
             - no_body
           name: backend
           upstream:
             name: >-
               outbound|3000||backend-listener.3scale.svc.cluster.local
             timeout: 5000
             url: 'http://backend-listener.3scale.svc.cluster.local'
         services:
           - id: '3'
             token: c12987<REDACTED>
             authorities:
               - '*'
      

      fetched 3Scale admin token like this:

      oc get secret -n 3scale system-seed -o json | jq -r .data.ADMIN_ACCESS_TOKEN | base64 -d
      

            Unassigned Unassigned
            rhn-support-keprice Kevin Price
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: