Skip to content

RFC: Environment variable based code injection #76

@ryanolee

Description

@ryanolee

Intro:

Currently lambda@edge has no support for bundling environment variables along side code. It is commonly recommended when using lambda@edge to use custom headers on origin requests to pass these variables instead. This is often fairly finicky to set up and cannot be used from viewer-request events.

Proposal:

When generating the code bundles for the various lambda functions an option is given to inject environment variables into the process.env by adding a proper definition to the file so they can be set at runtime.

An example of how this might look can be seen below

functions:
  onViewerRequest:
    handler: src/handler.onViewerRequest
    memorySize: 128
    timeout: 5
    lambdaAtEdge:
      distribution: 'TestDistribution'
      eventType: 'viewer-request'
      pathPattern: '/preflight'
      injectEnv: true

a new (optional) option injectEnv would be added to the configuration for lambdaAtEdge. This would default to false and all existing installations of the library should remain uneffected.

When the injectEnv option is set to true the environment variables associated with the function would automatically be prepended (directly in code) to the package. This would effectively bypass the existing limitation.

Caveats

Given this deals with bundled code there are a few limitations to this approach:

  • Injected env vars would be accessible in the S3 deployment bucket
  • Env vars can only reliably be injected at a file level inside the package. Meaning files with multiple lambdas in a file would be
    fairly hard to reconcile especially when mixed with regular lambdas. In theory we could change the function entry point on a per
    file basis and make sure the bundle is properly split for each function so the ENV is properly isolated.
  • Changing env vars would still require a redeploy to cloud formation. However env vars could still be changed and deployed to
    from CI environments

POC:

For now a fairly basic POC has been put together to demonstrate how this might work #77

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions