Freigeben über


Cert-Manager und Verschlüsseln („Let's Encrypt“) mit Application Gateway for Containers – Gateway-API

In diesem Handbuch wird veranschaulicht, wie Sie mithilfe des Zertifikat-Managers SSL/TLS-Zertifikate automatisch ausstellen und erneuern, um mindestens ein Front-End Ihres Azure Application Gateway für Containerbereitstellungen zu verwenden. Wir verwenden die Gateway-API, um die erforderlichen Ressourcen zu konfigurieren.

Für dieses Beispiel konfigurieren wir Cert-Manager-Zertifikate, die von „Let's Encrypt“ ausgestellt wurden, um eine End-to-End-Bereitstellung zu veranschaulichen, bei der Application Gateway für Container TLS-Offloading bereitstellt.

Ein Diagramm des Cert-Managers, der ein Zertifikat aus Let's Encrypt abruft und im Geheimnisspeicher von Kubernetes für TLS mit Application Gateway für Container speichert.

Damit Zertifikate von „Let's Encrypt“ ausgestellt werden, ist eine Herausforderung von der Autorität zum Überprüfen des Domänenbesitzes erforderlich. Diese Überprüfung erfolgt, indem der Cert-Manager das Erstellen einer Pod- und HTTPRoute-Ressource ermöglicht, die einen Endpunkt während der Zertifikatausstellung verfügbar macht, wodurch ihr Besitz des Domänennamens nachgewiesen wird.

Weitere Details zu Cert-Manager und „Let's Encrypt“ mit AKS im Allgemeinen finden Sie hier.

Voraussetzungen

  1. Wenn Sie die BYO-Bereitstellungsstrategie befolgen, stellen Sie sicher, dass Sie Ihre Application Gateway für Container-Ressourcen und Ihren ALB Controller einrichten

  2. Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie befolgen, stellen Sie sicher, dass Sie den ALB-Controller und die Application Gateway für Container-Ressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitstellen.

  3. Stellen Sie eine Beispiel-HTTP-Anwendung bereit, wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zum Veranschaulichen der Kopfzeilenumschreibung zu erstellen.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml
    

    Mit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:

    • ein Namespace namens test-infra
    • Zwei Dienste namens backend-v1 und backend-v2 im test-infra-Namespace
    • Zwei Bereitstellungen namens backend-v1 und backend-v2 im test-infra-Namespace

Erstellen einer Gatewayressource

Erstellen Sie eine neue Gateway-Ressource, die während des Abfragevorgangs auf HTTP-Anforderungen aus „Let's Encrypt“ lauscht.

Erstellen eines Gateways:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
    cert-manager.io/issuer: letsencrypt-cert
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    protocol: HTTP
    port: 80
    allowedRoutes:
        namespaces:
          from: Same
EOF

Hinweis

Wenn der ALB-Controller die Application Gateway für Container-Ressourcen in Azure Resource Manager erstellt, verwendet er die folgende Benennungskonvention für eine Front-End-Ressource: fe-<eight randomly generated characters>.

Wenn Sie den Namen der in Azure erstellten Frontendressource ändern möchten, sollten Sie die BYO-Bereitstellungsstrategie (Bring Your Own) befolgen.

Nachdem die Gatewayressource erstellt wurde, stellen Sie sicher, dass der Status gültig ist, dass der Listener programmiert ist und dem Gateway eine Adresse zugewiesen wird.

kubectl get gateway gateway-01 -n test-infra -o yaml

Beispielausgabe einer erfolgreichen Gatewayerstellung.

status:
  addresses:
  - type: IPAddress
    value: xxxx.yyyy.alb.azure.com
  conditions:
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Valid Gateway
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Application Gateway For Containers resource has been successfully updated.
    observedGeneration: 1
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Listener is accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    name: https-listener
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

Installieren von Cert-Manager

Installieren Sie Cert-Manager mithilfe von Helm:

helm install \
  cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --version v1.19.1 \
  --namespace cert-manager \
  --create-namespace \
  --set config.enableGatewayAPI=true \
  --set crds.enabled=true

Die Helminstallation erstellt drei Bereitstellungen und einige Dienste und Pods in einem neuen Namespace namens cert-manager. Außerdem werden clusterbezogene unterstützende Ressourcen wie RBAC-Rollen und benutzerdefinierte Ressourcendefinitionen installiert.

Erstellen eines ClusterIssuer

Erstellen Sie eine ClusterIssuer-Ressource, um zu definieren, wie der Cert-Manager mit „Let's Encrypt“ kommuniziert. In diesem Beispiel wird eine HTTP-Herausforderung verwendet. Während der Herausforderung erstellt der Cert-Manager eine HTTPRoute-Ressource und einen entsprechenden Pod, der einen Überprüfungsendpunkt darstellt, um den Besitz der Domäne zu beweisen.

Tipp

Andere Herausforderungen, die von „Let's Encrypt“ unterstützt werden, sind dokumentiert auf letsencrypt.org – Abfragetypen

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: test-infra
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory # production endpoint
    #server: https://acme-staging-v02.api.letsencrypt.org/directory # staging endpoint
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-private-key
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - name: gateway-01
                namespace: test-infra
                kind: Gateway
EOF

Überprüfen, ob die Ressource erstellt wurde

kubectl get ClusterIssuer -A -o yaml

Der Status True sollte angezeigt und Ready eingegeben werden.

  status:
    acme:
      lastPrivateKeyHash: x+xxxxxxxxxxxxxxxxxxxxxxx+MY4PAEeotr9XH3V7I=
      lastRegisteredEmail: your-email@example.com
      uri: https://acme-staging-v02.api.letsencrypt.org/acme/acct/165888253
    conditions:
    - lastTransitionTime: "2024-10-04T21:22:40Z"
      message: The ACME account was registered with the ACME server
      observedGeneration: 1
      reason: ACMEAccountRegistered
      status: "True"
      type: Ready

Erstellen eines Zertifikats

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: letsencrypt-cert
  namespace: test-infra
spec:
  secretName: letsencrypt-secret # name published to secret store
  issuerRef:
    name: letsencrypt-prod # ClusterIssuer resource name
    kind: ClusterIssuer
  dnsNames:
    - contoso.com # domain name to be used
EOF

Führen Sie den folgenden Befehl aus, um die Ausstellung des Zertifikats zu überprüfen. Wenn das Zertifikat ausgestellt wurde, sollte der Wert der READY-Spalte True sein.

kubectl get certificate letsencrypt-cert -n test-infra

Wenn das Zertifikat nicht ausgestellt wurde, können Sie den folgenden Befehl ausführen, um den Status einer Abfrage zu überprüfen.

Hinweis

Wenn das Zertifikat erfolgreich ausgestellt wurde, wird die Abfrage nicht mehr aufgeführt.

kubectl get challenges -n test-infra -o yaml

Aktivieren von HTTPS in der Gatewayressource

Ändern Sie das Gateway so, dass ein zweiter Listener hinzugefügt wird, um HTTPS-Anforderungen mit dem ausgestellten „Let's Encrypt“-Zertifikat zu beenden.

Erstellen eines Gateways:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
    cert-manager.io/issuer: letsencrypt-cert
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    protocol: HTTP
    port: 80
    allowedRoutes:
        namespaces:
          from: Same
  - name: https-listener
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - name: letsencrypt-secret
    allowedRoutes:
      namespaces:
        from: Same
EOF

Hinweis

Wenn der ALB-Controller die Application Gateway für Container-Ressourcen in Azure Resource Manager erstellt, verwendet er die folgende Benennungskonvention für eine Front-End-Ressource: fe-<eight randomly generated characters>.

Wenn Sie den Namen der in Azure erstellten Frontendressource ändern möchten, sollten Sie die BYO-Bereitstellungsstrategie (Bring Your Own) befolgen.

Erstellen sie eine HTTPRoute, die auf Ihren Hostnamen lauscht

Erstellen Sie eine HTTPRoute zum Verarbeiten von Anforderungen, die vom https-listener Listener empfangen werden.

Wichtig

Stellen Sie sicher, dass Sie contoso.com mit dem Domänennamen ersetzen, für den Sie erwarten, dass das Zertifikat ausgestellt wird.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: https-example
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
  hostnames:
  - "contoso.com"
  rules:
  - backendRefs:
    - name: backend-v1
      port: 8080
EOF

Nachdem die HTTPRoute-Ressource erstellt wurde, stellen Sie sicher, dass die Route Akzeptiert ist und die Ressource „Application Gateway für Container“ programmiert ist.

kubectl get httproute cert-manager-route -n test-infra -o yaml

Überprüfen Sie, ob der Status der Ressource „Application Gateway for Containers“ erfolgreich aktualisiert wurde.

status:
  parents:
  - conditions:
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Route is Accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    controllerName: alb.networking.azure.io/alb-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-01
      namespace: test-infra

Testen des Zugriffs auf die Anwendung

Jetzt können wir über den Hostnamen, der für Ihr Zertifikat verwendet wird, einige Datenverkehrsdaten an unsere Beispielanwendung senden.

Wichtig

Stellen Sie sicher, dass Sie contoso.com durch den Domänennamen ersetzen, für den Sie erwarten, dass das Zertifikat ausgestellt wird.

curl https://contoso.com/ -v 2>&1 | grep issuer

Die folgende Ausgabe wird angezeigt.

* issuer: C=US; O=Let's Encrypt; CN=R10

Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt, ein Zertifikat von „Let's Encrypt“ mit Cert-Manager ausgestellt und den Datenverkehr über das Application Gateway für Container an die Anwendung weitergeleitet.