Bootstrap Argo CD Without Creating a Circular Owner
Install the GitOps controller once, then let it own workload declarations without asking it to create its own cluster.
System map · Day 25
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — People and product entry points · Identity and policy · HelixWorks control plane · Generated application plane
Delivery and desired state
Covered — CI and immutable artifacts
Git desired state
Design target · not proved
Limits reconciliation to the approved repository and production overlay; the current ApplicationSet still follows mutable master.
Argo CD reconciliation
Source-backed today
Begins from one bounded installation action, then assumes ongoing ownership of its declared applications.
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths
Kubernetes or EKS control plane
Source-backed today
Hosts Argo CD and generated Application objects while Terraform and AWS remain the cluster owners.
Compute and traffic
Covered — Worker compute · Platform service workloads · Generated app workloadsAhead — Ambient mesh data plane
Storage and evidence
Covered — Infrastructure state · Product data and artifacts · Evidence and observability
Cluster desired and live state
Source-backed today
Records the bootstrap boundary and subsequent self-healing workload desired state.
The enterprise problem and today’s slice
Enterprise problem: GitOps becomes circular or unsafe when Argo CD is expected to recreate the EKS API that hosts it, manage its own first credential, or share one unrestricted identity across accounts. Whole-course context: The prior chapters define isolated clusters but do not claim they exist; today defines the bootstrap that runs only after one intended API answers. Today’s slice: Argo CD runs inside each private EKS cluster and applies argocd/project.yaml plus exactly one matching argocd/applicationsets/forge-{dev,staging,prod}.yaml; every ApplicationSet targets its environment-local https://kubernetes.default.svc. End-of-day evidence: A real bootstrap must record approval, pinned install digest, component UIDs, project policy, denied source/destination, environment, time, run, and audit IDs. Still unsolved: Without a reachable cluster and verified controller install, no GitOps success is claimed.
Customer outcome and implementation focus
The customer outcome is a reviewable bootstrap argo cd without creating a circular owner change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
EKS API, Argo CD application/controller/repo-server/ApplicationSet workloads, and AppProject policy; controller pods; Git, Kubernetes etcd, and audit evidence are authoritative; repo-server cache is disposable and not a source of truth.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Bootstrap Argo CD with a bounded, one-time owner
Apply the repository contracts
An unpinned remote install can change between runs, so verify a reviewed Argo CD release artifact before applying repository configuration. This production snippet uses exact current paths and the production context.
: "${AWS_PROFILE:?set the approved AWS profile}" "${AWS_REGION:?set the intended AWS region}" "${EXPECTED_ACCOUNT_ID:?set the intended 12-digit AWS account}"
actual_account="$(aws --profile "$AWS_PROFILE" --region "$AWS_REGION" sts get-caller-identity --query Account --output text)"
[ "$actual_account" = "$EXPECTED_ACCOUNT_ID" ] || { echo "AWS account mismatch" >&2; exit 1; }
aws --profile "$AWS_PROFILE" --region "$AWS_REGION" eks update-kubeconfig --name helixworks-forge-prod --alias helixworks-forge-prod
kubectl --context helixworks-forge-prod apply -f argocd/project.yaml
kubectl --context helixworks-forge-prod apply -f argocd/applicationsets/forge-prod.yaml
kubectl --context helixworks-forge-prod -n argocd get applicationsets,applications
kubectl --context helixworks-forge-prod -n argocd get application forge-prod -o wide
Key takeaways
GitOps begins with an explicit, bounded bootstrap owner.
- Argo CD cannot recreate an unavailable EKS API that hosts or receives its reconciliation.
- AppProject policy limits sources, destinations, and resources before sync.
SyncedandHealthyprove only the observed Git-to-cluster boundary.
Checklist
The handoff is complete when steady-state controllers no longer need bootstrap authority.
- [ ] Controller source and digest are pinned and reviewed
- [ ] Each environment has its own Argo instance, kube context, and fixed local destination
- [ ] Unapproved repository or namespace is denied
- [ ] Bootstrap session is revoked and audit retained