Receber por email
← Voltar para o catálogo

cert-manager-issuer-trust-review

Use esta skill ao revisar a configuração PKI do cert-manager para clusters Kubernetes. Acione-a quando o usuário perguntar sobre o escopo de Issuer ou ClusterIssuer, cobertura de CertificateRequestPolicy, riscos de SAN ou duração de certificado, distribuição de bundle do trust-manager, integração de CA de malha SPIFFE, saúde do webhook do cert-manager ou método de autenticação de CA na nuvem.

19estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: Apache-2.0

Como adicionar

/plugin marketplace add Raishin/vanguard-frontier-agentic

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/cert-manager-issuer-trust-review/svg)](https://www.skillteca.com.br/skills/cert-manager-issuer-trust-review)
#ai

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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](references/workflow-and-output.md)

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.
Compartilhar X LinkedIn