cert-manager Issuer Trust Review

SkillCloud & infra

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.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the cert-manager Issuer Trust Review skill

What this skill tells your AI

The instructions your AI receives, as published by vincentchuwaichow/vanguard-frontier-agentic in skills/cert-manager/cert-manager-issuer-trust-review/SKILL.md and read by ahel’s 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:

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.

Signals

GitHub stars
22
Forks
3
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
cert-manager-issuer-trust-review
Source
github.com/vincentchuwaichow/vanguard-frontier-agentic