aws / aws/containers-roadmap

[EKS] [request]: Support kustomize.buildOptions configuration in managed ArgoCD capability

Open
#2,807 0 comments 9 reactions 0 assignees View on GitHub
EKS EKS Capabilities
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

**Community Note:**
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.

**Tell us about your request:**
The EKS managed ArgoCD capability does not currently support configuring kustomize.buildOptions. Specifically, there is no way to set --enable-helm, which is required for the Kustomize + Helm integration pattern (HelmChartInflationGenerator).

In self-managed ArgoCD, this is configured in the argocd-cm ConfigMap:

data:
kustomize.buildOptions: "--enable-helm"

The UpdateCapability API only supports networkAccess and rbacRoleMappings — no server-level configuration options.

**Tell us about the problem you're trying to solve:**
We use ApplicationSet to manage multiple applications across clusters. Some of our applications use Kustomize overlays that include Helm charts via HelmChartInflationGenerator, along with additional manifests (ConfigMaps, RBAC resources, etc.). This is a common GitOps pattern documented in both the ArgoCD and Kustomize documentation.

Without --enable-helm, ArgoCD fails with:
"Manifest generation error: must specify --enable-helm"

Our current workaround is to unpack entire Helm charts into our Git repository and maintain them manually, which defeats the purpose of using Helm.

**Are you currently working around this issue?**
Yes — we are unpacking Helm charts directly into our ArgoCD apps repository for each chart we use. This is not ideal as it requires manual maintenance of chart contents instead of referencing chart versions.

**We have also considered:**
- Using ArgoCD's multiple sources feature (works for some cases but not all)
- Switching to self-managed ArgoCD (gives full control but loses the managed experience)

**Suggested Implementation**

Allow kustomize.buildOptions to be configured through the UpdateCapability API or
during capability creation, similar to how networkAccess and rbacRoleMappings are
configured today.

Contributor guide

Open the contributing guide

Research direction

Review the UpdateCapability API and capability-creation flow, comparing the existing networkAccess and rbacRoleMappings configuration paths. Check the referenced argocd-cm kustomize.buildOptions setting and confirm how --enable-helm is handled in managed ArgoCD. Done means users can configure this option through the managed capability API without unpacking Helm charts.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
api, cloud, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.