☰

Abgelaufene Zertifikate für Kubernetes Cert-Manager

tag-icon • tag-icon kubernetes google-kubernetes-engine cert-manager
Abgelaufene Zertifikate für Kubernetes Cert-Manager

Ich habe eine GKE-Kubernetes-Umgebung geerbt und versuche seit Tagen, das herauszufinden, weiß aber leider einfach nicht, was ich als Nächstes versuchen soll.

Der Cluster ist so eingerichtet, dass er den Cert-Manager (über Helm installiert) verwendet, um Let’s Encrypt-Zertifikate auf den Cluster anzuwenden. Aus irgendeinem Grund hat das über zwei Jahre lang perfekt funktioniert, aber ab dem 16.4. wurden mir in Browsern SSL-Warnungen für alle Notizen im Cluster angezeigt.

Beim Ausführen kubectl describe certificates site-cloud-tlsscheint das Zertifikat erneuert worden zu sein, wird aber nicht auf den eingehenden Datenverkehr angewendet.

Name:         site-cloud-tls
Namespace:    cs
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-06-02T09:55:05Z
  Generation:          34
  Owner References:
    API Version:           extensions/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Ingress
    Name:                  cs-nginx
    UID:                   7f312326-851c-11e9-8bf0-4201ac10000c
  Resource Version:        541365011
  UID:                     7f36cc40-851c-11e9-8bf0-4201ac10000c
Spec:
  Dns Names:
    site.cloud (changed name but is correct)
  Issuer Ref:
    Kind:       ClusterIssuer
    Name:       letsencrypt-dns
  Secret Name:  site-cloud-tls
Status:
  Conditions:
    Last Transition Time:  2022-04-24T05:26:13Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2022-06-15T17:01:48Z
Events:                    <none>

kubectl describe ingress
Name:             cs-nginx
Namespace:        cs
Address:          192.168.1.32
Default backend:  default-http-backend:80 (10.16.3.12:8080)
TLS:
  site-cloud-tls terminates site.cloud (changed naming but seems correct)
Rules:
  Host                       Path  Backends
  ----                       ----  --------
  site.cloud   
                             /   site:8080 (10.10.10.10:8080)

Annotations:                 certmanager.k8s.io/cluster-issuer: letsencrypt-dns
                             kubernetes.io/ingress.class: nginx
                             nginx.ingress.kubernetes.io/ssl-redirect: true
                             nginx.org/websocket-services: datahub
Events:                      <none>

Wir haben eine Staging-Umgebung, die ebenfalls betroffen war. Ich habe versucht, Cert-Manager und Nginx-Ingress neu zu installieren, konnte die Dinge aber leider nicht wieder zum Laufen bringen (wahrscheinlich aufgrund eines Konfigurationsfehlers, den ich gemacht habe).

Nach 3 Tagen weiß ich nicht, wo es langgeht, und kenne Kubernetes nicht gut genug, um zu wissen, was ich als Nächstes versuchen soll. Irgendwelche Tipps? Kann ich weitere Informationen bereitstellen, die hilfreich sein könnten?

Danke schön!

Antwort1

cluster-issuerDas Problem besteht hier darin, dass Sie sich in Ihrer Ingress-Definition auf eine Art beziehen :

Annotations:                 certmanager.k8s.io/cluster-issuer: letsencrypt-dns

Aber das von Ihnen definierte Objekt ist eine CertificateArt:

Name:         site-cloud-tls
Namespace:    cs
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate

Aus diesem Grund wird es nicht auf Ingress angewendet. Was Sie brauchen, ist die Erstellung einesAusstellerRessource in Kubernetes zur Handhabung des Zertifikats. Hier finden Sie ein Beispiel für eine einfacheGIPFEL ClusterIssuerManifestdatei:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: [email protected]
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
    - http01:
        ingress:
          class: nginx

verwandte Informationen