Kubernetes: cert-manager med FairSSL ACME

Q: Kan jeg bruge én issuer på tværs af namespaces?

Ja, brug en ClusterIssuer (som vores eksempel) i stedet for en namespace-bundet Issuer . ClusterIssuer er tilgængelig fra alle namespaces i klyngen.

Q: Hvor skal EAB-secreten ligge?

I samme namespace som cert-manager (typisk cert-manager ). ClusterIssuer-objektet refererer secreten via keySecretRef.name . Hvis cert-manager ikke kan finde den, så få en cert-manager admin til at bekræfte placeringen med kubectl get secret -n cert-manager .

cert-manager er den indbyggede ACME-klient til Kubernetes. Den kører som en controller i klyngen, opretter TLS Secrets automatisk og holder certifikaterne fornyet via ARI. Med FairSSL som ACME-udsteder bruger vi External Account Binding (EAB) og AutoDNS, så cert-manager ikke behøver DNS API-nøgler.

Understøttede versioner

Platform	Versioner	Kører på	ACME-klient
Kubernetes	VersionerGuiden sætter ingen versionsgrænse	Kører påKubernetes-clusteret	ACME-klientcert-manager, ARI fra v1.21 med feature gate ACMEUseARI

Opsætning

Vejledningen forudsætter at du allerede har cert-manager installeret i klyngen (Helm chart eller statisk manifest). Hvis ikke, så følg cert-manager-installationen først. Brug v1.21 eller nyere med feature gate ACMEUseARI, hvis du vil have ARI.

Trin 1: Opret EAB-secret

Hent EAB KID og HMAC-nøglen fra ACME-fanen i dit FairSSL-kontrolpanel og opret en Kubernetes Secret i cert-manager-namespacet.

kubectl create secret generic fairssl-eab-secret \
  --namespace cert-manager \
  --from-literal=secret=DIN_EAB_HMAC

Trin 2: Opret ClusterIssuer

ClusterIssuer er tilgængelig fra alle namespaces. Gem som fairssl-issuer.yaml og apply.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: fairssl-acme-issuer
spec:
  acme:
    email: acme-client@fairssl.dk
    server: https://fairssl.dk/acme
    privateKeySecretRef:
      name: fairssl-acme-account-key
    externalAccountBinding:
      keyID: DIN_EAB_KID
      keySecretRef:
        name: fairssl-eab-secret
        key: secret
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx

kubectl apply -f fairssl-issuer.yaml

Trin 3: Konfigurer FairSSL AutoDNS

Sørg for at hvert af de domæner, du anmoder certifikater for, har en CNAME viderestilling for _dnsauth.<domæne> til FairSSLs DNS-server i AutoDNS-menuen. Engangsopsætning per domæne. Selv om vi bruger HTTP-01-metoden i Kubernetes, så sikrer AutoDNS at fornyelsen virker uden manuel indgriben, hvis Ingress-pathen midlertidigt skulle være utilgængelig.

Trin 4: Anmod om et certifikat

Opret et Certificate-objekt der refererer til ClusterIssuer. cert-manager opretter automatisk en TLS Secret med navnet i secretName, som dine Deployments og Ingresses kan bruge.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: www-eksempel-dk
  namespace: default
spec:
  secretName: www-eksempel-dk-tls
  issuerRef:
    name: fairssl-acme-issuer
    kind: ClusterIssuer
  commonName: www.eksempel.dk
  dnsNames:
  - www.eksempel.dk
  - eksempel.dk

Trin 5: Bekræft og fejlfind

kubectl describe clusterissuer fairssl-acme-issuer
kubectl get certificate www-eksempel-dk -n default
kubectl describe certificate www-eksempel-dk -n default
kubectl get challenges -A

Når status viser Ready: True, indeholder www-eksempel-dk-tls dit certifikat og private nøgle og er klar til at blive monteret af din Deployment eller refereret af en Ingress. Du kan verificere det offentlige certifikat med FairSSLs SSL-scanner.

Ofte stillede spørgsmål

Find svar på de mest almindelige spørgsmål om SSL certifikater og FairSSL.

Hvorfor cert-manager og ikke en ekstern ACME-klient?

cert-manager er en indbygget Kubernetes-controller, der kører som en pod i klyngen. Den udsteder TLS Secrets som almindelige Kubernetes-objekter, så Deployments, Services og Ingresses kan referere certifikatet uden at vide noget om ACME. Det er den anbefalede løsning til klynger og afløser stort set alle ad-hoc-løsninger med eksterne klienter, der importerer PEM-filer.

Skal jeg åbne port 80 mod internettet?

Det afhænger af, hvilken valideringsmetode du vælger, og du har to muligheder. Med HTTP-01 (via en Ingress) skal du åbne port 80 fra internettet til den Ingress-controller, der serverer challenge-pathen. Med DNS-01 kræves ingen indgående port: med FairSSL AutoDNS opretter du én permanent CNAME viderestilling per domæne, cert-manager placerer sin challenge, og FairSSL svarer på den på vores side, så intet behøver være eksponeret på port 80. Til klynger, hvor du helst ikke vil åbne port 80, er DNS-01 med AutoDNS den anbefalede vej.

Bruger cert-manager ARI?

cert-manager understøtter ACME Renewal Information (ARI) fra v1.21, som eksperimentel funktion bag feature gate ACMEUseARI, der er slået fra som standard. Slår du den til, fornys certifikatet, når FairSSL anbefaler det, frem for kun ved en fast tidsplan. Uden den fornyer cert-manager ud fra certifikatets levetid. ARI er især vigtigt for 47-dages certifikater og for at modtage tidlig fornyelse ved tilbagekaldelseshændelser.

Kan jeg bruge én issuer på tværs af namespaces?

Ja, brug en ClusterIssuer (som vores eksempel) i stedet for en namespace-bundet Issuer. ClusterIssuer er tilgængelig fra alle namespaces i klyngen.

Hvor skal EAB-secreten ligge?

I samme namespace som cert-manager (typisk cert-manager). ClusterIssuer-objektet refererer secreten via keySecretRef.name. Hvis cert-manager ikke kan finde den, så få en cert-manager admin til at bekræfte placeringen med kubectl get secret -n cert-manager.

Hvad sker der, hvis certifikatet ikke kan udstedes?

cert-manager opretter en Order, der opretter en Challenge. Tjek dem med kubectl describe certificate <navn> og kubectl get challenges -A. De mest almindelige problemer er, at ingress-controlleren ikke ruter /.well-known/acme-challenge/ til cert-manager, eller at AutoDNS ikke er konfigureret korrekt for domænet.

Klar til at automatisere certifikater i Kubernetes?

Opret en gratis konto og bestil dit første certifikat. Et DV-certifikat udstedes på under 2 minutter.

Opret gratis konto Sammenlign certifikater