Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for AWS_LAMBDA_EXEC_WRAPPER #523

Open
RomainMuller opened this issue Oct 5, 2023 · 0 comments · May be fixed by #524
Open

Support for AWS_LAMBDA_EXEC_WRAPPER #523

RomainMuller opened this issue Oct 5, 2023 · 0 comments · May be fixed by #524

Comments

@RomainMuller
Copy link

RomainMuller commented Oct 5, 2023

Is your feature request related to a problem? Please describe.

@DataDog's ASM support for Lambda is implemented using a proxy around the AWS_LAMBDA_RUNTIME_API so we can intercept requests & responses and pass them to the WAF (for monitoring and possibly blocking).

This flow requires replacing the value of AWS_LAMBDA_RUNTIME_API with an alternate endpoint, which is normally achieved by setting the AWS_LAMBDA_EXEC_WRAPPER environment variable on the Lambda function to /opt/datadog_wrapper which then sets AWS_LAMBDA_RUNTIME_API to the host:port of the reverse proxy started by the Datadog extension.

Unfortunately, the provided runtimes (provided, provided.al2, and coincidentally go1.x) do not actually honor this environment variable and require special casing.

Describe the solution you'd like

It's unclear why custom/provided runtimes fail to honor this setting, and we would like to understand if it would be possible for the provided runtimes to actually do this.

Failing that, we think it would be feasible (although perhaps not desirable, notably because of the added cold start latency) for github.com/aws/aws-lambda-go to come with an init function that detects the AWS_LAMBDA_EXEC_WRAPPER environment variable, and when present, uses syscall.exec to enact the other runtime's flow.

Describe alternatives you've considered

We are considering a focalized solution in DataDog/datadog-lambda-go#143, but feel like this would be best addressed higher up in the dependency/responsibility chain.

Additional context

See: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-modify.html#runtime-wrapper.
See: https://github.com/DataDog/datadog-lambda-extension/blob/main/scripts/datadog_wrapper.

RomainMuller added a commit to RomainMuller/aws-lambda-go that referenced this issue Oct 16, 2023
Managed AWS Lambda runtimes wrap the function's runtime entry using a script
specified by the `AWS_LAMBDA_EXEC_WRAPPER` environment variable, however this is
not performed by provided runtimes (`provided`, `provided.al2`, `go1.x`).

This adds an `init` function that re-startes the current process after wrapping
it in the wrapper to emulate the behavior of other lambda runtimes, although
this will cause initialization of some other go packages to be run twice, which
will have an impact on cold start times.

See also: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-modify.html#runtime-wrapper

Fixes aws#523
@RomainMuller RomainMuller linked a pull request Oct 16, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant