MTLS front-end avec Passerelle d’application pour conteneurs – API Gateway

Ce document permet de configurer un exemple d’application qui utilise la ressource suivante depuis l’API Gateway. Les étapes sont fournies pour :

Créez une ressource de passerelle avec un écouteur HTTPS.
Créez une ressource HTTPRoute qui fait référence à un service principal.
Créez une ressource FrontendTLSPolicy dotée d’un certificat d’autorité de certification.

Background

Mutual Transport Layer Security (MTLS) est un processus qui s’appuie sur des certificats pour chiffrer les communications et identifier les clients vers un service. Cela permet à Passerelle d’application pour conteneurs d’améliorer l’état de la sécurité en faisant uniquement confiance aux connexions provenant d’appareils authentifiés.

Voir la figure suivante :

Le flux de certificat client valide montre un client présentant un certificat au front-end de Passerelle d’application pour conteneurs. Passerelle d’application pour conteneurs détermine que le certificat est valide et redirige la requête vers la cible back-end via proxy. La réponse est finalement retournée au client.

Le flux de certificat client révoqué montre un client présentant un certificat révoqué au front-end de Passerelle d’application pour conteneurs. Passerelle d’application pour conteneurs détermine que le certificat n’est pas valide et empêche la redirection de la requête vers le client via proxy. Le client reçoit l’erreur HTTP 400 (bad request) et la raison correspondante.

Prérequis

Si vous suivez la stratégie de déploiement BYO, veillez à configurer vos ressources de Passerelle d’application pour conteneurs et le contrôleur ALB.
Si vous suivez la stratégie de déploiement managé ALB, veillez à approvisionner votre contrôleur ALB et les ressources de Passerelle d’application pour conteneurs via la ressource personnalisée ApplicationLoadBalancer.
Déployez un exemple d’application HTTP :

Appliquez le fichier deployment.yaml suivant sur votre cluster pour créer un exemple d’application web et déployer des exemples de secrets afin de démontrer l’authentification mutuelle (mTLS) front-end.
```
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
```
Cette commande crée les éléments suivants sur votre cluster :
- Un espace de noms nommé test-infra
- Un service appelé echo dans l’espace de noms test-infra
- Un déploiement appelé echo dans l’espace de noms test-infra
- Un secret appelé listener-tls-secret dans l’espace de noms test-infra

Générer un ou plusieurs certificats

Pour cet exemple, nous allons créer un certificat racine et émettre un certificat client à partir de la racine. Si vous disposez déjà d’un certificat racine et d’un certificat client, vous pouvez ignorer ces étapes.

Générer une clé privée pour le certificat racine

openssl genrsa -out root.key 2048

Générer un certificat racine

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"

Générer une clé privée pour le certificat client

openssl genrsa -out client.key 2048

Créer une demande de signature de certificat pour le certificat client

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

Générer un certificat client signé par le certificat racine

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

Déployer les ressources d’API de passerelle requises

Déploiement managé ALB
Apportez votre propre déploiement BYO

Créer une passerelle

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

Remarque

Lorsque le contrôleur ALB crée les ressources Application Gateway pour conteneurs dans Azure Resource Manager, il utilise la convention d’affectation de noms suivante pour une ressource frontend : fe-<eight randomly generated characters>

Si vous souhaitez modifier le nom de la ressource front-end créée dans Azure, envisagez de suivre la stratégie de déploiement bring-your-own.

Définir les variables d’environnement suivantes

RESOURCE_GROUP='<resource group name of the Application Gateway For Containers resource>'
RESOURCE_NAME='alb-test'

RESOURCE_ID=$(az network alb show --resource-group $RESOURCE_GROUP --name $RESOURCE_NAME --query id -o tsv)
FRONTEND_NAME='frontend'
az network alb frontend create -g $RESOURCE_GROUP -n $FRONTEND_NAME --alb-name $AGFC_NAME

Créer une passerelle

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-id: $RESOURCE_ID
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
  addresses:
  - type: alb.networking.azure.io/alb-frontend
    value: $FRONTEND_NAME
EOF

Une fois la ressource de passerelle créée, vérifiez que l’état est valide, que l’écouteur est programmé et qu’une adresse est affectée à la passerelle.

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

Exemple de sortie de la création réussie de la passerelle :

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

Une fois la passerelle créée, créez une ressource HTTPRoute.

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

Une fois la ressource HTTPRoute créée, vérifiez que l’itinéraire est accepté et que la ressource Passerelle d’application pour conteneurs est programmée.

kubectl get httproute https-route -n test-infra -o yaml

Vérifiez que l’état de la ressource de Passerelle d’application pour conteneurs a été correctement mis à jour.

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

Créez un secret Kubernetes avec kubectl qui contient la chaîne de certificats au certificat client.

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

Créer un objet 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

Une fois l’objet FrontendTLSPolicy créé, consultez l’état de l’objet pour vérifier que la stratégie est valide :

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

Exemple de sortie de la création d’un objet FrontendTLSPolicy valide :

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

Tester l’accès à l’application

Nous sommes maintenant prêts à envoyer du trafic vers notre exemple d’application, via le FQDN attribué au front-end. Utilisez la commande suivante pour obtenir le nom de domaine complet :

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

Effectuez un curling du nom de domaine complet de votre front-end sans le certificat client.

curl --insecure https://$fqdn/

Notez que la réponse signale qu’un certificat est requis.

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

Effectuez un curling du nom de domaine complet qui présente le certificat client généré.

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

Notez que la réponse provient du service back-end derrière Passerelle d’application pour conteneurs.

Félicitations ! Vous venez d’installer le contrôleur ALB, de déployer une application back-end, de vous authentifier via un certificat client et de retourner le trafic de votre service back-end via Passerelle d’application pour conteneurs.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2024-11-05