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: techtide-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---56# cert-manager Issuer Trust Review78## Purpose910Review 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.1112## Lean operating rules1314- 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.2324## References2526Load these only when needed:27- [Workflow and output contract](references/workflow-and-output.md)2829## Response minimum3031Return, 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.
TechTideOhio