aldengolab/argocd-helm-eso-setups
skills/argocd-helm-eso-setups/SKILL.md
Debugging and managing GitOps clusters where ArgoCD, Helm, and ESO (ExternalSecrets Operator) coexist. Ownership symptoms: kubectl patches revert immediately, git push doesn't update a deployed resource, ArgoCD prune leaves resources behind, two tools fight over the same ConfigMap/Secret/CRD, duplicate deployments from the same chart under different names. ESO symptoms: ExternalSecret template expressions render as empty strings inside Helm chart templates/, SecretSynced True but the rendered secret value is empty (provider returned empty for the referenced field). Covers: ownership model, selfHeal behavior (including ignoreDifferences for standby-mode replica scaling), prune scope, fixed-name collision points, the "where do I make this change?" decision tree, Helm template escaping for ESO expressions, secrets provider field type diagnosis, keeping sensitive infrastructure values out of public Git repos (runtime sed substitution, role-based nodeSelectors instead of hostnames), and non-root container secret volume permissions (fsGroup + defaultMode).
tools
Updated Apr 10, 2026
$ install --global
skillsauthnpx skillsauth add aldengolab/lorist argocd-helm-eso-setupsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 24, 2026, 8:42 PM1.7s1 file scanned
SKILL.md
- name:
- argocd-helm-eso-setups
- description:
- |
- (ExternalSecrets Operator) coexist. Ownership symptoms:
- kubectl patches revert
- deployments from the same chart under different names. ESO symptoms:
- ExternalSecret
- for the referenced field). Covers:
- ownership model, selfHeal behavior
ArgoCD + Helm + ESO: Debugging and Management
The Ownership Model
Helm and ArgoCD track ownership independently using different mechanisms:
| Tool | Ownership marker | Where it lives |
|---|---|---|
| Helm | meta.helm.sh/release-name: <release> | resource annotation |
| Helm | app.kubernetes.io/managed-by: Helm | resource label |
| ArgoCD | argocd.argoproj.io/tracking-id: <app>:<group>/<kind>:<ns>/<name> | resource annotation |
A resource can have both markers simultaneously — this is a conflict. Helm thinks it owns it; ArgoCD thinks it owns it. Changes made by either tool will be contested by the other.
Reading ownership at a glance
kubectl get <kind> <name> -n <namespace> -o yaml \
| grep -E 'tracking-id|release-name|managed-by'
Interpreting the output:
- Only
release-name/managed-by: Helm→ Helm-only. Changes needhelm upgrade. - Only
tracking-id→ ArgoCD-only. Changes go in git. - Both present → Contested. One will win based on selfHeal + sync frequency.
- Neither → Manually applied or created by a controller. ArgoCD won't prune it.
"Where Do I Make This Change?" Decision Tree
Is the resource listed in `argocd app resources <app>`?
├── YES → Does the Application have selfHeal: true?
│ ├── YES → Make the change in git (values file or template). kubectl will revert.
│ └── NO → kubectl patch works, but git is still preferred for durability.
└── NO → Is it annotated with meta.helm.sh/release-name?
├── YES → Run `helm upgrade <release> <chart> -n <namespace>` after updating values.
└── NO → It's unmanaged. kubectl apply/patch is the only option.
Consider whether it should be brought under management.
Detailed Reference
For in-depth procedures, read the relevant reference file when needed:
- Four Rules + conflict diagnostics + ownership transfer:
Read skills/argocd-helm-eso-setups/references/ownership-rules.md - ESO integration (Helm template escaping, 1Password silent empty, force-sync):
Read skills/argocd-helm-eso-setups/references/eso-integration.md - Public repo security + non-root containers (sensitive values, nodeSelectors, secret volume perms):
Read skills/argocd-helm-eso-setups/references/deployment-security.md
Related Skills
aldengolab/ubuntu-secureboot-pxe-netboot
development
VerifiedTrustedCommunity
Build a UEFI Secure Boot PXE netboot server for Ubuntu autoinstall. Use when: designing or implementing network boot infrastructure for automated Ubuntu provisioning with Secure Boot enabled. Covers the complete chain: signed shim+GRUB selection, TFTP layout, kernel parameters, autoinstall config requirements, and post-install bootstrapping scripts. Also applicable when debugging an existing PXE setup that uses the wrong GRUB binary or config paths.
SKILL.mdUpdated Apr 10, 2026
aldengolab/pxe-grub-persistent-server-pattern
development
VerifiedTrustedCommunity
Design pattern for running a persistent PXE/TFTP server that safely coexists with already-installed nodes. Use when: building PXE infrastructure that should stay always-on, designing automated bare-metal provisioning in GitOps/Kubernetes environments, or any PXE setup where UEFI boot order has network boot first. Eliminates boot loops without requiring UEFI firmware changes.
SKILL.mdUpdated Apr 10, 2026
aldengolab/orwell-clear-writing
development
VerifiedTrustedCommunity
This skill governs all prose output — Claude's own responses, documentation, PR descriptions, commit messages, README content, comments, and any text the user asks to draft or edit. It should also be used when the user asks to "review my writing", "edit this for clarity", "make this clearer", "simplify this text", "rewrite this", "check my prose", "tighten this up", or "make this more concise". Based on George Orwell's "Politics and the English Language" (1946).
SKILL.mdUpdated Apr 10, 2026
aldengolab/k8s-hostnetwork-port-conflict
development
VerifiedTrustedCommunity
Debug Kubernetes pods using hostNetwork: true that crash with "Address already in use" or "failed to create listening socket for port N". Use when: (1) a hostNetwork pod container is in CrashLoopBackOff and logs show a port bind failure, (2) the port works fine in non-hostNetwork pods but fails with hostNetwork, (3) you need to identify which host-level process holds a port from within Kubernetes (no SSH). Covers /proc/net/udp inspection and kubectl debug node with nsenter.
SKILL.mdUpdated Apr 10, 2026