aws-eks: Helm Chart support for TAR archives

[daniel-rhoades]

Describe the feature

When using the L2 construct within the aws_eks_v2_alpha library defining a HelmChart construct, a chartAsset can optionally be specified instead of specifying a repository, but currently, only assets packaged as ZIP archives are supported:

https://github.com/aws/aws-cdk/blob/3d948c4eeb6ffc8e5d3203220fe7799dffbd59ef/packages/%40aws-cdk/aws-eks-v2-alpha/lib/kubectl-handler/helm/init.py#L20-L29

This creates an issue (e.g. non AWS-managed EKS drivers) when pulling a chart (on Linux/MacOS) which is then provided as a TGZ, for example:

helm pull aws-secrets-manager/secrets-store-csi-driver-provider-aws -d temp/charts

I suggest the kubectl-handler should support the typical formats returned helm pull ... across the main OS types.

Use Case

When deploying helm charts to an air-gapped EKS cluster, they must be hosted in a way that is accessible to the kubectl-handler to pull it.

One way of achieving this is to upload helm charts using the CDK S3 Assets feature, Python example:

TEMP_CHARTS = 'temp/charts'  # Generated outside of CDK

cluster = ...  # An EKS Cluster created using the L2 construct from `aws_eks_v2_alpha`

driver_version = '1.4.8'

stack = Stack.of(construct)
prefix = f'{stack.account}.dkr.ecr.{stack.region}.amazonaws.com'

eks.HelmChart(
      self, 'SecretsStoreCsiDriverChart', cluster=cluster, namespace='kube-system',
      chart_asset=s3_assets.Asset(
          self, 'ChartAsset', path=f'{TEMP_CHARTS}/secrets-store-csi-driver-${driver_version}.zip'
      ),
      values={
          'linux': {
              'image': {
                  'repository': f'{prefix}/kubernetes/csi-secrets-store/driver'
              },
              'crds': {
                  'image': {
                      'repository': f'{prefix}/kubernetes/csi-secrets-store/driver-crds'
                  }
              }
          }
      }
  )

In the above, the default references to public repositories have been replaced with references to private ECR repos into which the required driver container image has been pushed.

The problem arises because the path to the asset (f'{TEMP_CHARTS}/secrets-store-csi-driver-${driver_version}.zip') currently references a .zip file, when in practice the output for this chart from a helm pull ... command is a .tgz.

Proposed Solution

Support multiple archive formats (at least ZIP and TAR GZ) within the kubectl-handler/helm module. Python has the builtin package tarfile which should suffice.

Workaround

Extract the non-ZIP'd helm chart package and repackage it as a ZIP, achieved using the following example shell snippet:

repo_name='aws-secrets-manager'
chart_name='secrets-store-csi-driver-provider-aws'

temp_dir='temp/charts'
mkdir -p "$temp_dir"
helm pull "${repo_name}/${chart_name}" -d "$temp_dir" --untar
version=$(helm show chart "temp/charts/${chart_name}" | awk '/version/ {print $2}')

(export temp_dir chart_name version && cur=$(pwd) && cd "${temp_dir}/${chart_name}" && zip -r "${cur}/${temp_dir}/${chart_name}-${version}.zip" .)

Other Information

On the face of it, pushing a copy of the chart into ECR should also work, but I struggled to get the kubectl-handler to successfully pull from it, hence resorted to referencing the chart as an S3 assets.

Acknowledgements

• [x] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

CDK version used

2.1002.0 (build 09ef5a0)

Environment details (OS name and version, etc.)

MacOS

[pahud]

Sounds good! Making this a p2 FR. Feel free to submit your PR. And let's move this forward from there. Thank you.