prefixRewrite cannot be used with lambda backends

[lilley2412]

Describe the bug

When a lambda upstream is used with options.prefixRewrite, the request results in an auth exception from aws lambda invoke. When prefixRewrite is removed, the request works regardless of what the route path is.

To Reproduce Steps to reproduce the behavior:

1. Create a lambda upstream (not sure if it matters but i'm using IAM for service accounts, not static aws credentials)
2. Create a route against the lamba and use prefixRewrite:

   routes:
     - matchers:
         - prefix: /my-path
       options:
         prefixRewrite: /
       routeAction:
         single:
           destinationSpec:
             aws:
               logicalName: lambda-function-name
           upstream:
             name: lambda-upstream-name
             namespace: gloo-system

3. Make a request to the route
4. Observe the following error:

   <AccessDeniedException>
   <Message>Unable to determine service/operation name to be authorized</Message>
   </AccessDeniedException>

   If the prefixRewrite is removed, the request succeeds.

Expected behavior Prefix rewrite should not cause an authorization failure. If prefixRewrite is removed, and the route path is changed to /, it also works. Using rewrite should result in the same behavior.

Additional context Add any other context about the problem here, e.g.

• Gloo Edge version 1.8.2
• Kubernetes version 1.21
• Using IAM for service accounts, not aws static credentials

[sam-heilbron]

Setting this to a Medium. If the work required to resolve this is determined to be larger than a medium, it should not be resolved as part of this work. Instead we'll need to re-scope and prioritize the work.

[lilley2412]

We found that regexRewrite does work in place of prefixRewrite:

      options:
        regexRewrite: 
          pattern:
            regex: /my-path
          substitution: "/"

[chrisgaun]

Moving to the backlog

[Ati59]

A customer is requesting this. I have tested it with 1.14.3 (service account and CLI creds) and the problems remains (following this installation guide : https://docs.solo.io/gloo-edge/latest/guides/traffic_management/destination_types/aws_lambda/eks-service-accounts/). Here is details of my (unsuccessful) local tests :

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: default
  namespace: gloo-system
spec:
  virtualHost:
    domains:
    - '*'
    routes:
    - matchers:
      - prefix: /a/b/lambda
      options:
        prefixRewrite: /lambda
      routeAction:
        single:
          destinationSpec:
            aws:
              logicalName: ati-lambda-test
              unwrapAsApiGateway: true
              wrapAsApiGateway: true
          upstream:
            name: lambda
            namespace: gloo-system

My lambda function just returns the event (discovered by gloo) :

import json

def lambda_handler(event, context):
    print(type(context))
    return {
        'statusCode': 200,
        "headers": {
            "Content-Type": "application/json"
        },
        'body': json.dumps({
            "event": event
        })
    }

With prefixRewrite and wrapAsApiGateway :

With prefixRewrite but without wrapAsApiGateway:

With regexRewrite and wrapAsApiGateway:

I try several cases (playing with wrapAsApiGateway and try the workaround regexRewrite) but could not make it working. Sometimes we get 500 error, sometimes 404 and sometimes get the JSON back without the path change.

[nfuden]

Given our current ordering of lambda we will either need to rework our entire setup to use router filter options along with lambda

[github-actions[bot]]

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.