[python_lambda] Add scenario for testing the python tracer for AWS Lambda

[florentinl]

Motivation

In the context of my internship, I am implementing Appsec for AWS Lambda through the python tracer to replace the current implementation which relies on the extension (the agent in the context of lambda).

The goal of this pull request is to be able to do end-to-end testing of the python tracer in the context of AWS Lambda.
To avoid relying on provisioning resources in AWS, I am attempting to emulate the AWS Lambda behaviour using a system-test Docker scenario.

A typical AWS Serverless deployment works with an AWS Managed Load Balancer such as APIGateway, ALB, or the Lambda Function Url service, the load balancer converts the incoming HTTP request to a json representation called an Event that is passed to the AWS Lambda runtime to execute the function.

graph LR
    A[Incoming HTTP Request] -->|HTTP| B[AWS Managed Load Balancer]
    B -->|event: request as JSON| C[AWS Lambda]

Loading

AWS Provides the AWS Lambda Runtime Interface Emulator to simulate the Lambda runtime inside a Docker container and a cli to emulate a local APIGateway (AWS SAM cli).

Leveraging these two tools, we can envision a DockerScenario with the following architecture:

graph LR
    A[Incoming HTTP Request] -->|HTTP| B[LambdaProxy]
    B -->|event: request as JSON| C[LambdaWeblog]

Loading

With the following components:

• LambdaWeblog: A weblog app written as a lambda function, running with the AWS Lambda RIE
• LambdaProxy: A small flask app, to convert http request to lambda events, invoke the function with this event and return the result as an http response. This one relies on primitives of AWS SAM cli, a tool to emulate an API Gateway locally

A specificity of this scenario is that the extension runs inside the LambdaWeblog because it needs access to the Lambda Runtime API, this requires the proxy to be able to send traces back to the weblog instead of sending them to a dedicated agent.

As a first step, this PR contains a single scenario to test Appsec capabilities for the APIGateway Rest API event type. The goal would be to eventually (in following PRs) emulate all other types of http events that a Lambda can receive: APIGateway HTTP API, Application Load Balancer, Lambda Function Url.

Changes

Additions:

• A weblog for AWS Lambda python APIGateway Rest API with only a few routes for now
• A helper container LambdaProxy to relay system-test http request to invoke the Lambda Runtime Interface
• A new Scenario type LambdaScenario to orchestrate the two containers and configure the Proxy

Modifications:

• Make the Proxy configurable so that it can send traces to the lambda extension instead of the dedicated agent container.
• Add a new scenario of the new type LambdaScenario: appsec_lambda_deafult and add to it all appsec related tests of the default scenario

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed and the CI green, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• If PR title starts with [<language>], double-check that only <language> is impacted by the change
• No system-tests internal is modified. Otherwise, I have the approval from R&P team
• A docker base image is modified?
  • the relevant build-XXX-image label is present
• A scenario is added (or removed)?
  • Get a review from R&P team

[cbeauchesne]

This scenario is not in the CI, so it's not tested