Freigeben über

Front-End-MTLS mit Application Gateway für Container – Gateway-API

Diese Anleitung hilft beim Einrichten einer Beispielanwendung, die die folgenden Ressourcen aus der Gateway-API verwendet. Es sind Schritte vorgesehen:

  • Erstellen einer Gateway-Ressource mit einem HTTPS-Listener.
  • Erstellen einer HTTPRoute-Ressource, die auf einen Back-End-Dienst verweist.
  • Erstellen Sie eine FrontendTLSPolicy-Ressource mit einem Zertifizierungsstellenzertifikat.

Hintergrund

Mutual Transport Layer Security (MTLS) ist ein zertifikatbasierter Prozess, um die Kommunikation zu verschlüsseln und Clients für einen Dienst zu identifizieren. Auf diese Weise kann Application Gateway für Container seinen Sicherheitsstatus weiter erhöhen, indem nur Verbindungen von authentifizierten Geräten als vertrauenswürdig angesehen werden.

Dies wird in der folgenden Abbildung veranschaulicht:

Ein Diagramm, das den Front-End-MTLS-Prozess für Application Gateway für Container zeigt.

Der Flow eines gültigen Clientzertifikats zeigt einen Client, der dem Front-End von Application Gateway für Container ein Zertifikat präsentiert. Application Gateway für Container stellt fest, dass das Zertifikat gültig ist, und leitet die Anforderung an das Back-End-Ziel weiter. Die Antwort wird letztendlich an den Client zurückgegeben.

Der Flow eines gesperrten Clientzertifikats zeigt einen Client, der dem Front-End von Application Gateway für Container ein gesperrtes Zertifikat präsentiert. Application Gateway für Container stellt fest, dass das Zertifikat ungültig ist und verhindert, dass die Anforderung an den Client weitergeleitet wird. Der Client wird eine „HTTP 400 ungültige Anforderung“ und einen entsprechenden Grund erhalten.

Voraussetzungen

  1. Wenn Sie der BYO-Bereitstellungsstrategie folgen, müssen Sie Ihre Application Gateway für Container-Ressourcen und den ALB-Controller einrichten.

  2. Wenn Sie der Strategie der durch ALB verwalteten Bereitstellung folgen, müssen Sie den ALB-Controller und die Application Gateway für Container-Ressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitstellen.

  3. Bereitstellen einer HTTP-Beispielanwendung:

    Wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zu erstellen und Beispielgeheimnisse bereitzustellen, um die gegenseitige Front-End-Authentifizierung (mTLS) zu demonstrieren.

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

    Mit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:

    • Ein Namespace namens test-infra
    • Ein Dienst, der im Namespace echo als test-infra bezeichnet wird
    • Eine Bereitstellung, die im Namespace echo als test-infra bezeichnet wird
    • Ein Geheimnis, das im Namespace listener-tls-secret als test-infra bezeichnet wird

Generieren von Zertifikaten

In diesem Beispiel werden wir ein Stammzertifikat erstellen und ein Clientzertifikat aus dem Stamm ausstellen. Wenn Sie bereits über ein Stammzertifikat und ein Clientzertifikat verfügen, können Sie diese Schritte überspringen.

Generieren eines privaten Schlüssels für das Stammzertifikat

openssl genrsa -out root.key 2048

Generieren eines Stammzertifikats

openssl req -x509 -new -nodes -key root.key -sha256 -days 1024 -out root.crt -subj "/C=US/ST=North Dakota/L=Fargo/O=Contoso/CN=contoso-root"

Generieren eines privaten Schlüssels für das Clientzertifikat

openssl genrsa -out client.key 2048

Erstellen einer Zertifikatsignaturanforderung für das Clientzertifikat

openssl req -new -key client.key -out client.csr -subj "/C=US/ST=North Dakota/L=Fargo/O=Contoso/CN=contoso-client"

Generieren eines Clientzertifikats, das vom Stammzertifikat signiert ist

openssl x509 -req -in client.csr -CA root.crt -CAkey root.key -CAcreateserial -out client.crt -days 1024 -sha256

Bereitstellen der erforderlichen Gateway-API-Ressourcen

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
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: mtls-listener
    port: 443
    protocol: HTTPS
    allowedRoutes:
      namespaces:
        from: Same
    tls:
      mode: Terminate
      certificateRefs:
      - kind : Secret
        group: ""
        name: listener-tls-secret
EOF

Hinweis

Wenn der ALB-Controller das Anwendungsgateway für Containerressourcen in Azure Resource Manager erstellt, verwendet er die folgende Benennungskonvention für eine Frontend-Ressource: fe-<eight randomly generated characters>

Wenn Sie den Namen der in Azure erstellten Frontend-Ressource ändern möchten, sollten Sie die Bring-Your-Own-Bereitstellungsstrategie beachten.

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

Nachdem das Gateway erstellt wurde, erstellen Sie eine HTTPRoute-Ressource.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: https-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
  rules:
  - backendRefs:
    - name: echo
      port: 80
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 https-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

Erstellen Sie ein Kubernetes-Geheimnis mithilfe von kubectl, das die Zertifikatkette zum Clientzertifikat enthält.

kubectl create secret generic ca.bundle -n test-infra --from-file=ca.crt=root.crt

Erstellen einer FrontendTLSPolicy

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: FrontendTLSPolicy
metadata:
  name: mtls-policy
  namespace: test-infra
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: gateway-01
    namespace: test-infra
    sectionNames:
    - mtls-listener
  default:
    verify:
      caCertificateRef:
        name: ca.bundle
        group: ""
        kind: Secret
        namespace: test-infra
EOF

Nachdem das FrontendTLSPolicy-Objekt erstellt wurde, überprüfen Sie den Status auf dem Objekts, um sicherzustellen, dass die Richtlinie gültig ist:

kubectl get frontendtlspolicy mtls-policy -n test-infra -o yaml

Beispielausgabe einer gültigen FrontendTLSPolicy-Objekterstellung:

status:
  conditions:
  - lastTransitionTime: "2023-06-29T16:54:42Z"
    message: Valid FrontendTLSPolicy
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted

Testen des Zugriffs auf die Anwendung

Jetzt können Sie über den FQDN, der dem Front-End zugewiesen ist, einigen Datenverkehr an die Beispielanwendung senden. Verwenden Sie den folgenden Befehl, um den FQDN abzurufen:

fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

Durchführen von „curl“ für den FQDN Ihres Frontends ohne das Clientzertifikat.

curl --insecure https://$fqdn/

Beachten Sie die Warnmeldungen, dass ein Zertifikat erforderlich ist.

curl: (56) OpenSSL SSL_read: OpenSSL/1.1.1k: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

Sperrt den FQDN, der das generierte Clientzertifikat darstellt.

curl --cert client.crt --key client.key --insecure https://$fqdn/

Beachten Sie, dass die Antwort vom Back-End-Dienst hinter Application Gateway für Container stammt.

Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt, über ein Clientzertifikat authentifiziert und den Datenverkehr von Ihrem Back-End-Dienst über Application Gateway für Container zurückgegeben.

  • Last updated on