Follow-up to #343. That PR enabled mTLS but the Helm upgrade failed to apply and rolled back, so the agents stayed on the fragile register-based path (they're only Running now because the pods happened to get recreated and re-registered against a fresh LAPI — not durable).
Cause
Chart 0.24.0's agent/bouncer/appsec Certificate templates emit secretTemplate:unconditionally while its child blocks (annotations/labels) are guarded. With nothing set it renders as secretTemplate: null, and cert-manager's webhook rejects it:
Certificate "crowdsec-agent" is invalid: spec.secretTemplate: Invalid value: "null":
spec.secretTemplate in body must be of type object
(The lapi cert template guards the whole key, which is why only the other three failed — and why helm template alone didn't catch it: the null is only rejected at admission, not at render.)
Fix
Set tls.certManager.secretTemplate.labels so secretTemplate renders as a valid object.
Verified against the live cert-manager webhook this time (kubectl apply --dry-run=server): all 4 Certificates and 3 Issuers accepted.
Post-merge
Flux can fetch again (git URL fixed separately), so this should reconcile automatically. Will confirm the Helm upgrade succeeds, the agent certs issue, the DaemonSet stays Ready on the TLS path, and infrastructure goes green.
Follow-up to #343. That PR enabled mTLS but the Helm upgrade **failed to apply** and rolled back, so the agents stayed on the fragile register-based path (they're only Running now because the pods happened to get recreated and re-registered against a fresh LAPI — not durable).
## Cause
Chart 0.24.0's `agent`/`bouncer`/`appsec` Certificate templates emit `secretTemplate:` **unconditionally** while its child blocks (`annotations`/`labels`) are guarded. With nothing set it renders as `secretTemplate: null`, and cert-manager's webhook rejects it:
```
Certificate "crowdsec-agent" is invalid: spec.secretTemplate: Invalid value: "null":
spec.secretTemplate in body must be of type object
```
(The `lapi` cert template guards the whole key, which is why only the other three failed — and why `helm template` alone didn't catch it: the null is only rejected at admission, not at render.)
## Fix
Set `tls.certManager.secretTemplate.labels` so `secretTemplate` renders as a valid object.
**Verified against the live cert-manager webhook** this time (`kubectl apply --dry-run=server`): all 4 Certificates and 3 Issuers accepted.
## Post-merge
Flux can fetch again (git URL fixed separately), so this should reconcile automatically. Will confirm the Helm upgrade succeeds, the agent certs issue, the DaemonSet stays Ready on the TLS path, and `infrastructure` goes green.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The mTLS fix in #343 failed to apply: chart 0.24.0's agent/bouncer/appsec
Certificate templates emit `secretTemplate:` unconditionally while its
child blocks are guarded, so with nothing configured it rendered as null
and cert-manager's webhook rejected it (spec.secretTemplate must be of
type object). The helm upgrade failed and rolled back, so agents stayed
on the fragile register-based path.
Set tls.certManager.secretTemplate.labels so secretTemplate renders as a
valid object. Verified via kubectl apply --dry-run=server against the
live cert-manager webhook: all 4 Certificates now accepted.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🤖Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit 3a152ef28ff0f3e87fc217f49c1cd6b15e2b64b6.
Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.
Summary
This PR fixes a CrowdSec Helm chart 0.24.0 bug where cert-manager's webhook was rejecting the agent/bouncer/appsec Certificate specs. The chart emits spec.secretTemplate: null unconditionally, but cert-manager requires it to be an object. The fix adds a standard Kubernetes label to secretTemplate, making it render as a valid non-null object. The change is minimal, verified against the live cert-manager webhook, and correctly placed in the HelmRelease values.
🟢 Nits
kubernetes/infrastructure/crowdsec/helmrelease.yaml:76–84 — The multi-line comment explaining the chart bug is helpful for future maintainers; indentation and placement are correct. No issues.
Tests
No test changes needed; this is a Helm values fix verified manually against the actual cert-manager webhook validation (kubectl apply --dry-run=server). The PR author reports all 4 Certificates and 3 Issuers passed webhook validation after this fix.
Recommendation
Looks reasonable — no blocking issues; the fix is well-understood and verified.
🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `3a152ef28ff0f3e87fc217f49c1cd6b15e2b64b6`.
> Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review.
---
## Summary
This PR fixes a CrowdSec Helm chart 0.24.0 bug where cert-manager's webhook was rejecting the agent/bouncer/appsec Certificate specs. The chart emits `spec.secretTemplate: null` unconditionally, but cert-manager requires it to be an object. The fix adds a standard Kubernetes label to `secretTemplate`, making it render as a valid non-null object. The change is minimal, verified against the live cert-manager webhook, and correctly placed in the HelmRelease values.
## 🟢 Nits
**kubernetes/infrastructure/crowdsec/helmrelease.yaml:76–84** — The multi-line comment explaining the chart bug is helpful for future maintainers; indentation and placement are correct. No issues.
## Tests
No test changes needed; this is a Helm values fix verified manually against the actual cert-manager webhook validation (`kubectl apply --dry-run=server`). The PR author reports all 4 Certificates and 3 Issuers passed webhook validation after this fix.
## Recommendation
Looks reasonable — no blocking issues; the fix is well-understood and verified.
<!-- pr-review:sha=3a152ef28ff0f3e87fc217f49c1cd6b15e2b64b6 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
review-bot
Follow-up to #343. That PR enabled mTLS but the Helm upgrade failed to apply and rolled back, so the agents stayed on the fragile register-based path (they're only Running now because the pods happened to get recreated and re-registered against a fresh LAPI — not durable).
Cause
Chart 0.24.0's
agent/bouncer/appsecCertificate templates emitsecretTemplate:unconditionally while its child blocks (annotations/labels) are guarded. With nothing set it renders assecretTemplate: null, and cert-manager's webhook rejects it:(The
lapicert template guards the whole key, which is why only the other three failed — and whyhelm templatealone didn't catch it: the null is only rejected at admission, not at render.)Fix
Set
tls.certManager.secretTemplate.labelssosecretTemplaterenders as a valid object.Verified against the live cert-manager webhook this time (
kubectl apply --dry-run=server): all 4 Certificates and 3 Issuers accepted.Post-merge
Flux can fetch again (git URL fixed separately), so this should reconcile automatically. Will confirm the Helm upgrade succeeds, the agent certs issue, the DaemonSet stays Ready on the TLS path, and
infrastructuregoes green.🤖 Generated with Claude Code
🤖 Automated review — model
claude-haiku-4-5-20251001(complexity: trivial), commit3a152ef28ff0f3e87fc217f49c1cd6b15e2b64b6.Summary
This PR fixes a CrowdSec Helm chart 0.24.0 bug where cert-manager's webhook was rejecting the agent/bouncer/appsec Certificate specs. The chart emits
spec.secretTemplate: nullunconditionally, but cert-manager requires it to be an object. The fix adds a standard Kubernetes label tosecretTemplate, making it render as a valid non-null object. The change is minimal, verified against the live cert-manager webhook, and correctly placed in the HelmRelease values.🟢 Nits
kubernetes/infrastructure/crowdsec/helmrelease.yaml:76–84 — The multi-line comment explaining the chart bug is helpful for future maintainers; indentation and placement are correct. No issues.
Tests
No test changes needed; this is a Helm values fix verified manually against the actual cert-manager webhook validation (
kubectl apply --dry-run=server). The PR author reports all 4 Certificates and 3 Issuers passed webhook validation after this fix.Recommendation
Looks reasonable — no blocking issues; the fix is well-understood and verified.