Thundercloud12 opened a new pull request, #6818:
URL: https://github.com/apache/camel-k/pull/6818
## Summary
Adds cert-manager auto-discovery to the Ingress trait. When enabled, Camel K
detects whether cert-manager is installed, resolves a `ClusterIssuer` or
`Issuer` (either forced by name or auto-discovered), and annotates the
generated Ingress so cert-manager's own ingress-shim handles certificate
issuance and renewal.
**Camel K never creates `Certificate` resources itself** — this keeps
certificate lifecycle management entirely inside cert-manager, where it belongs.
Fixes #5857
### New Trait Options
* `tls-cert-manager-auto` — enable cert-manager auto-discovery
* `tls-issuer-name` — force a specific issuer, bypassing auto-discovery
* `tls-issuer-kind` — `Issuer` or `ClusterIssuer` (defaults to
`ClusterIssuer`)
### Design Notes / Tradeoffs for Reviewers
* **Multiple issuers:** When auto-discovery finds more than one
`ClusterIssuer`/`Issuer`, the first one is selected rather than requiring
exactly one unambiguous match. This was chosen for simplicity over
correctness-by-refusal. Happy to switch to an "only when exactly one issuer is
found" behavior if reviewers prefer.
* **`t.Host` fallback:** The cert-manager path also activates when only
`ingress.host` is set. This is intentional because `ingress.host` is the field
most users actually configure. This fallback is scoped strictly to the
cert-manager path (only when `tlsSecretName` is empty) and does not change the
existing manual-TLS behavior covered by
`TestConfigureTLSWithoutHostsIngressTraitDoesSucceed`.
* **RBAC widening:** Adds `get`/`list`/`watch` permissions for `issuers` and
`clusterissuers` (`cert-manager.io`) to the operator's `ClusterRole`/`Role`.
These permissions are read-only. `clusterissuers` are cluster-scoped even in
the namespaced installation mode; this is flagged for review against the
project's RBAC threat model.
* **E2E scope:** Rather than performing a live HTTPS round-trip through a
real ingress controller—which would require additional infrastructure such as
DNS, a tunnel, or an ingress addon—the E2E test verifies the issued certificate
cryptographically. It parses the TLS secret and checks the DNS SAN and
certificate expiry after confirming that cert-manager populated it.
### Implementation
* `pkg/util/certmanager/` — new cert-manager detection package
(`IsInstalled`, `ListClusterIssuers`, `GetClusterIssuer`, `GetIssuer`), built
on `unstructured` without introducing a cert-manager Go client dependency.
Absence of cert-manager degrades cleanly to "not found" rather than returning
an error.
* `pkg/trait/ingress.go` — adds `resolveCertManagerIssuer()` and reworks the
TLS block in `Apply()` to merge the manual-TLS and cert-manager paths.
* **RBAC:** Adds the required `ClusterRole`/`Role`/`RoleBinding` permissions
for `issuers` and `clusterissuers`.
* `e2e/cert-manager/` — new cert-manager E2E workflow with its own Makefile
target, mirroring the structure of the existing `e2e/gateway` suite.
## Test Plan
* [x] Unit tests: `pkg/util/certmanager` — 8 tests covering installation
detection and all three "absent" failure modes
* [x] Unit tests: `pkg/trait/ingress_test.go` — 6 additional tests covering:
* cert-manager not installed → no-op
* no issuer found → no-op
* successful auto-discovery
* successful forced-issuer resolution
* forced issuer missing → error
* forced issuer configured but cert-manager not installed → error
* [x] Existing Ingress trait tests — 12 tests pass unmodified, confirming no
regression to manual TLS behavior
* [x] `go build ./...`
* [x] `gofmt`
* [x] `./script/check_licenses.sh`
* [ ] E2E suite (`make test-e2e`) — not run in this environment;
reviewers/CI to confirm
---
🤖 Generated with Claude Code on behalf of Thundercloud12
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
