Track the ClusterIssuer instead of gitignoring it

[3uzbcqje]

clusterissuer.yaml has been gitignored since 2024-04-14, which left the root of every TLS certificate on this cluster with no history, no review and no drift detection. If it were edited or deleted, nothing would notice or restore it.

The gitignore wasn't protecting anything

Git history tells the story plainly — it was tracked for a week first:

2024-04-07  ea73fb3  adds clusterissuer.template.txt AND clusterissuer.yaml
2024-04-14  6d575ac  "Prod clusterissuer" — flips staging→prod,
                     deletes clusterissuer.yaml, adds the .gitignore entry

The version deleted in 6d575ac contained the same subscription ID, client ID and email address the ignore now appears to guard, in plaintext. This reads as an ordinary "don't commit generated output" instinct, applied in the commit that turned the file into a template — not a security decision.

None of the values are sensitive by this repo's own convention

Value	Already tracked?
subscription ID 86f3145a-…	yes — applications/external-dns/values.yaml
resource group equalvote	yes — 9 files
prod.equal.vote	yes — 9 files
gmail@evanstucker.com	yes — 3 files
client ID ebafbf2e-…	no — the only absent value

But external-dns's identity (747dcea4-…) and loki's (098d7377-…) are both committed in plaintext. A managed-identity client ID is an identifier, not a credential — the repo already treats them that way.

No hidden variance

I rendered the template with the live values and diffed against the cluster: identical apart from the comment header. The manifest added here is byte-identical to what's deployed, so this changes nothing at sync time.

Why secrets/

It's the only directory an auto-syncing app applies raw manifests from — secrets/kustomization.yaml already carries namespaces.yaml exactly this way, and bootstrap-secrets runs with selfHeal: true and prune: true.

The directory name is a poor fit for a ClusterIssuer, and I'd rather say so than pretend otherwise. Moving it later means changing bootstrap-secrets' path in application.yaml, which needs a manual kubectl apply — the thing #57 moved away from. Happy to do that separately if you'd prefer a cluster-resources/ directory.

It can't live with cert-manager: that app is a Helm chart from the ApplicationSet and can't carry extra manifests.

One subtle fix

The .gitignore entry is now anchored to /clusterissuer.yaml. Unanchored, the pattern matches at any depth — it was already silently ignoring secrets/clusterissuer.yaml before I anchored it, which would have made this PR quietly do nothing.

The root-level render stays ignored, so the envsubst workflow still works locally.

Template kept

utils/clusterissuer.template.txt remains as the record of where the five values come from, with a note that rendering it no longer deploys anything — copy the result into secrets/clusterissuer.yaml and push instead.

After merge

kubectl -n argocd get app bootstrap-secrets -o jsonpath='{.status.sync.status}'
kubectl get clusterissuer letsencrypt-prod -o jsonpath='{.status.conditions[*].type}'   # want Ready
kubectl get certificate -A    # unchanged

The manifest matches live, so ArgoCD should adopt it with an empty diff.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XTsEHfxxGsxGkKWfyQCYmr

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: ed17843a-437b-40ba-bd2e-49e0c0e76f0b

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[jacksonloper]

Along the same lines as #73, I vaguely think we want

metadata:
  annotations:
    argocd.argoproj.io/sync-options: Delete=false

here so it would survive an application delete.

[ArendPeter]

Can we change this to elections@equal.vote ?

I'd like to add you add the other dev leads to that email group anyway, so that way the work any certificate issues can be shared