cert-manager Issuer Trust Review
Purpose
Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) authorization coverage, certificate SAN wildcard and duration risks, trust-manager CA bundle distribution blast radius, SPIFFE/service-mesh CA integration, and cloud-backed CA authentication method. cert-manager's security posture depends on whether namespace-scoped request authorization exists — without CertificateRequestPolicy, any namespace can issue a certificate for any DNS name from a shared ClusterIssuer.
Lean operating rules
- Prefer live evidence (
kubectl get clusterissuer,issuer -A -o yaml, kubectl get certificaterequestpolicy -o yaml, kubectl get certificate -A -o yaml) when the active client exposes it; otherwise fall back to official cert-manager documentation and sanitized YAML from the user.
- Separate confirmed facts from inference. If CertificateRequestPolicy deployment, certificate health, or trust-manager bundle scope was not directly queried, say so.
- Treat no CertificateRequestPolicy deployed cluster-wide as a critical finding — any cert request in any namespace is auto-approved against any ClusterIssuer.
- Treat a ClusterIssuer backed by a corporate private CA with no namespace restriction via CertificateRequestPolicy as a high finding — any namespace can request corp-trusted certs.
- Treat Certificate
spec.dnsNames containing wildcards like *.internal.company.com for a single microservice as a high finding — overly broad trust grants.
- Treat
spec.duration exceeding 90 days for workload certs as a high finding; certs with duration: 87600h (10 years) are critical.
- Treat cert-manager-webhook in a degraded or failing state as a high finding — no new cert renewals can complete.
- Treat a trust-manager Bundle with no namespace selector distributing CA bundles to all namespaces as a medium finding unless intentionally cluster-wide.
- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
References
Load these only when needed:
- Workflow and output contract
Response minimum
Return, at minimum:
- the scoped target (ClusterIssuer, Issuer, Certificate, CertificateRequestPolicy, or trust-manager Bundle) and evidence level,
- the issuer type and backing CA (self-signed, ACME, AWS PCA, Azure Key Vault, Vault, etc.) and whether it is namespace-scoped or cluster-scoped,
- CertificateRequestPolicy presence and subject/issuer constraint coverage,
- certificate SAN scope and duration for any reviewed Certificate resources,
- trust-manager Bundle distribution scope,
- the safest next actions and any assumptions or blockers.
1---2name: cert-manager-issuer-trust-review3description: Use this skill when reviewing cert-manager PKI configuration for Kubernetes clusters. Trigger when the user asks about Issuer or ClusterIssuer scope, CertificateRequestPolicy coverage, certificate SAN or duration risks, trust-manager bundle distribution, SPIFFE mesh CA integration, cert-manager webhook health, or cloud CA authentication method.4---5
6# cert-manager Issuer Trust Review
7
8## Purpose
9
10Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) authorization coverage, certificate SAN wildcard and duration risks, trust-manager CA bundle distribution blast radius, SPIFFE/service-mesh CA integration, and cloud-backed CA authentication method. cert-manager's security posture depends on whether namespace-scoped request authorization exists — without CertificateRequestPolicy, any namespace can issue a certificate for any DNS name from a shared ClusterIssuer.
11
12## Lean operating rules
13
14- Prefer live evidence (`kubectl get clusterissuer,issuer -A -o yaml`, `kubectl get certificaterequestpolicy -o yaml`, `kubectl get certificate -A -o yaml`) when the active client exposes it; otherwise fall back to official cert-manager documentation and sanitized YAML from the user.
15- Separate confirmed facts from inference. If CertificateRequestPolicy deployment, certificate health, or trust-manager bundle scope was not directly queried, say so.
16- Treat no CertificateRequestPolicy deployed cluster-wide as a critical finding — any cert request in any namespace is auto-approved against any ClusterIssuer.
17- Treat a ClusterIssuer backed by a corporate private CA with no namespace restriction via CertificateRequestPolicy as a high finding — any namespace can request corp-trusted certs.
18- Treat Certificate `spec.dnsNames` containing wildcards like `*.internal.company.com` for a single microservice as a high finding — overly broad trust grants.
19- Treat `spec.duration` exceeding 90 days for workload certs as a high finding; certs with `duration: 87600h` (10 years) are critical.
20- Treat cert-manager-webhook in a degraded or failing state as a high finding — no new cert renewals can complete.
21- Treat a trust-manager Bundle with no namespace selector distributing CA bundles to all namespaces as a medium finding unless intentionally cluster-wide.
22- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
23
24## References
25
26Load these only when needed:
27- [Workflow and output contract](references/workflow-and-output.md)
28
29## Response minimum
30
31Return, at minimum:
32- the scoped target (ClusterIssuer, Issuer, Certificate, CertificateRequestPolicy, or trust-manager Bundle) and evidence level,
33- the issuer type and backing CA (self-signed, ACME, AWS PCA, Azure Key Vault, Vault, etc.) and whether it is namespace-scoped or cluster-scoped,
34- CertificateRequestPolicy presence and subject/issuer constraint coverage,
35- certificate SAN scope and duration for any reviewed Certificate resources,
36- trust-manager Bundle distribution scope,
37- the safest next actions and any assumptions or blockers.
aibot88