fix(aws-eks): support http proxy in EKS onEvent lambda

[ryparker]

Summary

Currently when a user wants to route all of the EKS lambda's aws-sdk-js requests through a proxy then they are instructed to configure an env var named HTTP_PROXY or http_proxy.

e.g.

const cluster = new eks.Cluster(this, 'hello-eks', {
  version: eks.KubernetesVersion.V1_21,
  clusterHandlerEnvironment: {
    'http_proxy': 'http://proxy.myproxy.com'
  }
});

However the JS SDK requires further configuration to enable proxy support.

This PR:

The below changes have been refactored to avoid use of NodeJsFunction. See the PR comments below for reasoning and updated changes.

• Adds a package.json with the dependency 'http-proxy-agent' to the cluster-resource-handler/ lambda bundle
• Uses NodeJSFunction to install lambda dependencies and bundle.
• Adds a condition that checks the environment for HTTP_PROXY or http_proxy values. If present then configures the aws-sdk to use that proxy (using http-proxy-agent).

Note: I placed the http-proxy-agent in the devDependencies of package.json. If the dependency is placed in the dependencies section then the CDK builder throws an error: NPM Package cluster-resources-handler inside jsii package '@aws-cdk/aws-eks', can only have devDependencies

Fixes: SIM D29159517, #12469

Tested this using squid proxy on an ec2 instance within the same VPC as the EKS cluster.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[ryparker]

@otaviomacedo Would you be able to help me get this released once the CI passes? I found the release docs state to run ./bump.sh to perform a minor bump. Is that all that I need to do to trigger the release?

[ryparker]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 444cae4
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

CI is failing but this passes locally. Any ideas? Will continue to investigate on my end.

Failure:

@aws-cdk/aws-eks: Bundling asset Stack/@aws-cdk--aws-eks.ClusterResourceProvider/OnEventHandler/Code/Stage...
@aws-cdk/aws-eks: FAIL test/service-account.test.js (15.937 s)
@aws-cdk/aws-eks:   � service account › add Service Account › defaults should have default namespace and lowercase unique id
@aws-cdk/aws-eks:     Failed to bundle asset Stack/@aws-cdk--aws-eks.ClusterResourceProvider/OnEventHandler/Code/Stage, bundle output is located at /tmp/cdk.outzgYgUF/bundling-temp-4d81264e075d2e80c50708b10b07860eeab9a1dfc587b7e5c4cc63407f6728bf-error: Error: bash exited with status 1
@aws-cdk/aws-eks:       396 |
@aws-cdk/aws-eks:       397 |   /**
@aws-cdk/aws-eks:     > 398 |    * Determine the directory where we're going to write the bundling output
@aws-cdk/aws-eks:           |             ^
@aws-cdk/aws-eks:       399 |    *
@aws-cdk/aws-eks:       400 |    * This is the target directory where we're going to write the staged output
@aws-cdk/aws-eks:       401 |    * files if we can (if the hash is fully known), or a temporary directory
@aws-cdk/aws-eks:       at AssetStaging.bundle (../core/lib/asset-staging.ts:398:13)
@aws-cdk/aws-eks:       at AssetStaging.stageByBundling (../core/lib/asset-staging.ts:246:10)
@aws-cdk/aws-eks:       at stageThisAsset (../core/lib/asset-staging.ts:137:35)
@aws-cdk/aws-eks:       at Cache.obtain (../core/lib/private/cache.ts:24:13)
@aws-cdk/aws-eks:       at new AssetStaging (../core/lib/asset-staging.ts:162:44)
@aws-cdk/aws-eks:       at new Asset (../aws-s3-assets/lib/asset.ts:68:21)
@aws-cdk/aws-eks:       at AssetCode.bind (../aws-lambda/lib/code.ts:183:20)
@aws-cdk/aws-eks:       at new Function (../aws-lambda/lib/function.ts:331:29)
@aws-cdk/aws-eks:       at new NodejsFunction (../aws-lambda-nodejs/lib/function.ts:51:5)
@aws-cdk/aws-eks:       at new ClusterResourceProvider (lib/cluster-resource-provider.ts:63:21)

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[ryparker]

I'm a little concerned that the CI all of a sudden passed without an explicit change. Now it looks like it failed when mergify updated the branch with master.

It seems to be a bundling error. I was able to reproduce the error locally by removing esbuild as a dependency. My PR uses the NodeJsFunction to bundle a NPM directory which uses esbuild.

I also noticed that NodeJsFunction is not used in any other package. I then did some issue searching and found this issue where someone states

“Because the CDK uses jsii and the CDK team doesn’t currently want to bundle esbuild in the CDK we cannot use the Node.js API or declare esbuild as a peer dependency unfortunately.”

link to comment

If we don’t support bundling esbuild with our packages then perhaps I should avoid using the NodeJsFunction in the aws-eks package. Instead I could create a lambda layer with proxy-agent installed. @otaviomacedo thoughts?

[ryparker]

In this last commit I implemented a new package @aws-cdk/lambda-layer-node-proxy-agent which creates a LambdaLayerVersion that contains the NPM dependency proxy-agent. This allowed me to remove use of NodeJsFunction from the aws-eks package.

This layer can be reused in other modules if needed. If there are any other custom resources that implement a Node Lambda which happens to use something like the aws-sdk-js package then proxy support is probably not supported, however by adding this layer it should be easy to add support.

I needed this layer so that I could have the proxy-agent dependency available. proxy-agent is required in order to configure the aws-sdk-js to route requests through a provided proxy url. I could have installed the smaller module http-proxy-agent to the layer, however I installed the full proxy-agent library to the layer for future implementations where we would like to support other protocols (https,websockets,etc).

I also copied the way we allow a user to override layers for the kuberctl lambdas using the optional kubectlLayer prop. A similar optional prop named onEventLayer was added to the aws-eks's Cluster and FargateCluster resources. I chose the prop name onEventLayer because onEvent is the name of the lambda we add the lambda-layer-node-proxy-agent to.

[ryparker]

I'm deploying an EKS cluster using the locally built CDK packages and manually checking if the provided proxy is in fact being used.

[ryparker]

I can confirm that the onEvent lambda routes traffic to the proxy using this fix.

[ryparker]

@otaviomacedo, re-requested your review since I made a major refactor of my fix.

[ryparker]

@Mergifyio refresh

[mergify]

Command refresh: success

Pull request refreshed

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 5760312
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).