Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Implémentation de référence de l'équilibrage de charge de couche 7 HAProxy

Google Distributed Cloud (GDC) air-gapped fournit un équilibreur de charge de couche 4 (L4) géré intégré, mais de nombreuses applications d'entreprise nécessitent des fonctionnalités avancées de couche 7 (L7), telles que le routage basé sur l'hôte, la gestion centralisée de TLS et la répartition complexe du trafic. Historiquement, cela se fait à l'aide de l'API Ingress, qui est désormais considérée comme figée dans la communauté Kubernetes.

Cette architecture de référence fournit une solution d'équilibrage de charge de couche 7 autogérée. En déployant le contrôleur Open Source HAProxy populaire sur un cluster standard GDC, les clients peuvent acheminer de manière transparente le trafic L7 vers des environnements hybrides. Cette architecture utilise la terminaison TLS (HTTPRoute) pour acheminer le trafic en fonction de l'indication du nom du serveur (SNI) vers les pods conteneurisés intégrés et les applications hébergées sur des machines virtuelles externes.

Architecture

Diagramme de l'architecture pour l'équilibrage de charge HAProxy de couche 7 sur GDC sous air gap.

Les principaux composants de la solution sont les suivants :

Client : entité qui lance des requêtes HTTPS pour interagir avec les applications.
Cluster standard GDC : GDC fournit un moyen intégré de créer des clusters Kubernetes Vanilla. Dans cette solution, le cluster hébergera l'équilibreur de charge L7 et ses contrôleurs, ainsi que les charges de travail et le service sans interface graphique pour les VM externes.
Équilibreur de charge L4 GDC : équilibreur de charge L4 intégré servant de point d'entrée, distribuant le trafic TCP/443 directement aux pods Kubernetes exécutant les contrôleurs.
Contrôleurs d'entrée : opérateurs HAProxy exécutés dans le cluster standard. Ils surveillent les ressources Ingress et mettent à jour dynamiquement les proxys sous-jacents. Le contrôleur d'entrée HAProxy Ingress sera utilisé dans l'implémentation suivante.
Entrée : ressources Kubernetes standardisées définissant le port d'écoute physique (443) et les règles de routage d'hôte basées sur SNI avec terminaison TLS.
Charge de travail conteneurisée (pods) : déploiement Kubernetes standard exposé en interne avec un Service Kubernetes régulier.
Charge de travail basée sur une VM (externe) : charge de travail hébergée sur une VM externe sur le réseau du projet, exposée au proxy à l'aide d'un Service Kubernetes sans interface graphique et d'un point de terminaison personnalisé contenant l'adresse IP directe de la VM.
Registre Harbor : registre de conteneurs privé utilisé pour stocker et diffuser les images de proxy et d'application dans l'environnement air-gapped.

Dans le cluster standard, vous créez trois espaces de noms :

L'espace de noms load-balancer héberge le contrôleur d'entrée HAProxy et la charge de travail de l'équilibreur de charge HAProxy :
L'espace de noms hello-app héberge le Deployment, un Service et une Ingress pour la charge de travail du conteneur de démonstration :
L'espace de noms vm-app héberge un service sans interface graphique qui expose l'adresse IP de la VM externe, un EndpointSlice qui pointe vers l'adresse IP externe et une Ingress :

Avant de commencer

Avant de déployer cette solution, assurez-vous de disposer des prérequis suivants :

Logiciels requis : helm, docker, kubectl

Connexion à la CLI et configuration locale : téléchargez la CLI gdcloud depuis la console GDC et configurez votre environnement localement :

export USER_NAME="USER_NAME"
export PROJECT_ID="PROJECT_ID"
export ZONE="ZONE"
export ORG_NAME="ORG_NAME"
export GDC_URL="GDC_URL"

gdcloud components install gdcloud-k8s-auth-plugin

gdcloud config set core/organization_console_url \
  https://console.$ORG_NAME.$ZONE.$GDC_URL
gdcloud config set core/zone $ZONE
gdcloud config set core/project ${PROJECT_ID}

gdcloud auth login # use --login-config-cert option in case of TLS error

Configuration du projet : créez un projet dans votre environnement GDC sous air gap pour contenir les ressources :
```
gdcloud projects create $PROJECT_ID
```

Rôles IAM : accordez à votre utilisateur les rôles Administrateur de cluster et Administrateur de cluster standard pour gérer les ressources Kubernetes, ainsi que le rôle Administrateur d'instance Harbor pour envoyer des images :

# Grant standard cluster and cluster admin roles
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=standard-cluster-admin

# Grant Harbor instance admin role
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=harbor-instance-admin

Créer un cluster standard

Cette section vous explique comment configurer un cluster Kubernetes standard dans votre environnement GDC sous air gap. Un cluster standard fournit une base flexible et robuste pour déployer diverses charges de travail, y compris le contrôleur d'entrée HAProxy et vos applications personnalisées. Les étapes suivantes vous permettront de vous assurer que votre cluster est correctement configuré et accessible pour les déploiements ultérieurs.

Identifiez les types d'images de machine virtuelle disponibles en exécutant la commande suivante :
```
gdcloud compute machine-types list
```
Sélectionnez un type de machine approprié pour les nœuds de calcul de votre cluster. Pour ce tutoriel, il est recommandé d'utiliser un type de machine avec au moins 4 processeurs virtuels.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Obtenez le fichier kubeconfig du serveur d'API de gestion et définissez un alias :

export CLUSTER_NAME="CLUSTER_NAME"

KUBECONFIG=kubeconfig-admin.yaml gdcloud clusters \
  get-credentials ${ORG_NAME}-admin

alias km="kubectl --kubeconfig kubeconfig-admin.yaml"

Créez un cluster standard avec deux nœuds de calcul :

km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
  namespace: ${PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${CLUSTER_NAME}-node-pool
EOF

Pour en savoir plus sur les options disponibles, consultez la documentation.

La création d'un cluster standard peut prendre jusqu'à 60 minutes. Pour vérifier l'état, exécutez la commande suivante :

km get clusters/${CLUSTER_NAME} \
  -n ${PROJECT_ID} \
  --watch

Une fois le cluster prêt, le résultat doit afficher l'état "Running" (En cours d'exécution), comme suit :

NAME         STATE     K8S VERSION
my-cluster   Running   1.30.12-gke.300

Une fois le cluster prêt, récupérez ses identifiants :

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${CLUSTER_NAME} \
  --standard \
  --project ${PROJECT_ID} \
  --zone ${ZONE}

Créez un alias pour rendre les commandes kubectl plus concises dans le reste de ce guide. Cet alias sera utilisé pour interagir avec le cluster standard :
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Créez des espaces de noms pour le contrôleur, l'application conteneurisée de démonstration "hello-app" et l'application de démonstration basée sur une VM :
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Créer et intégrer un registre Harbor

Harbor est un registre d'images de conteneurs avec une assistance intégrée dans GDC sous air gap. Cette section vous explique comment intégrer un registre Harbor à votre cluster standard, y compris comment configurer les identifiants et les secrets pour permettre l'extraction et l'envoi sécurisés d'images.

Créez une instance Harbor dans votre projet.
Créez un projet Harbor dans votre instance Harbor.

Définissez les variables d'environnement :

export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME"
export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL"
export HARBOR_PROJECT="HARBOR_PROJECT"
export IMAGE_PULL_SECRET_NAME="harbor-secret"

Connectez-vous à l'instance Harbor à l'aide d'un compte robot :
```
docker --config=./docker login ${HARBOR_INSTANCE_URL}
```

Créez les secrets dans le cluster standard :

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n load-balancer

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n hello-app

Déployer une application conteneurisée de démonstration

Cette section décrit le déploiement d'une application conteneurisée de démonstration (hello-app) dans votre cluster Kubernetes GDC sous air gap. Vous allez créer les ressources Kubernetes Deployment et Service nécessaires pour exécuter hello-app et l'exposer en interne dans le cluster, en le préparant à l'accès à l'aide de l'équilibreur de charge L7.

Importez un exemple d'image pour l'application conteneurisée de démonstration dans Harbor :

docker pull gcr.io/google-samples/hello-app:1.0 \
  --platform linux/amd64
docker tag gcr.io/google-samples/hello-app:1.0 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0

Déployez le fichier manifeste suivant dans le cluster standard :

cat << EOF > hello-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: hello-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-server
        image: ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: ${IMAGE_PULL_SECRET_NAME}
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app
  namespace: hello-app
spec:
  type: ClusterIP
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

kk apply -f hello-app.yaml

Vérifiez ensuite que le déploiement et le service sont présents.

kk get svc,deploy -n hello-app

Déployer une application de démonstration dans une VM

Cette section décrit le déploiement d'une application de démonstration dans une machine virtuelle (VM) en dehors de votre cluster Kubernetes. En configurant un serveur HTTP sur une VM, vous simulerez une application externe que l'équilibreur de charge peut exposer, ce qui démontrera sa capacité à gérer le trafic vers des ressources à l'intérieur et à l'extérieur du cluster.

Commencez par créer une VM pour l'application de démonstration :

Ouvrez la console GDC dans votre navigateur Web.
Sélectionnez le même projet que celui dans lequel vous avez créé votre cluster Kubernetes standard.
Ouvrez le menu, puis cliquez sur Machines virtuelles.
Cliquez sur Créer une instance.
Nommez la VM vm-workload. Une image à deux processeurs virtuels suffit pour cet exemple.
Pour l'image du disque de démarrage, sélectionnez une distribution Ubuntu 22.04, qui est fournie avec Python préinstallé.
Cliquez sur Créer.
Attendez quelques minutes que la VM soit prête.
Établissez une connexion SSH à la VM :
1. Dans la console GDC, cliquez sur la VM.
2. Cliquez sur Se connecter avec SSH.

Une fois connecté à la console SSH, exécutez la commande suivante :

mkdir ~/simple-server
cd ~/simple-server
echo 'Welcome to my VM!' > index.html
python3 -m http.server --bind 0.0.0.0 8080 &

Pour acheminer le trafic vers une VM, créez un service sans interface graphique (sans sélecteurs). Il sera mappé manuellement à l'adresse IP interne de la VM à l'aide d'une ressource EndpointSlice.

kk apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: vm-app-svc
  namespace: vm-app
spec:
  ports:
  - protocol: TCP
    port: 443
    targetPort: 443
EOF

Obtenez l'adresse IP de la VM vm-workload en exécutant la commande suivante :

gdcloud compute instances list --project ${PROJECT_ID} \
  | grep workload-vm | awk '{print $3}'

Le résultat correspondra à l'adresse IP de la VM qui sera nécessaire pour configurer la ressource EndpointSlice.

Créez la ressource EndpointSlice qui se connectera au service sans sélecteur de l'application de VM et adressez l'adresse IP de la VM vers laquelle le trafic doit être acheminé.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: vm-app-endpoints
  namespace: vm-app
  labels:
    kubernetes.io/service-name: vm-app-svc
addressType: IPv4
ports:
  - port: 8080
endpoints:
  - addresses:
    - "VM_IP"
    conditions:
      ready: true

Créer des certificats autosignés

Cette section vous explique comment créer des certificats TLS et des secrets Kubernetes pour sécuriser la communication de vos applications basées sur des conteneurs et des VM. Ce guide utilise des certificats autosignés pour plus de commodité, mais dans les environnements de production, vous devez utiliser des certificats de qualité production, comme décrit dans la section Facultatif : Utiliser des certificats prêts pour la production. Choisissez des exemples de noms de domaine arbitraires pour ces applications. En établissant des connexions sécurisées, vous garantissez l'intégrité et la confidentialité des données pour les clients qui accèdent à votre application via le contrôleur d'entrée HAProxy.

Pour l'application conteneurisée, nous créons un certificat autosigné et l'enregistrons en tant que secret dans l'espace de noms de l'équilibreur de charge. Il sera utilisé pour TLS lors de la requête k8s-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-containerized.key \
  -out tls-containerized.crt \
  -subj "/CN=k8s-app.example.com" \
  -days 365

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

Pour l'application de VM, un certificat autosigné semblable est émis et enregistré. Il sera utilisé pour TLS lors de la requête vm-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-vm.key \
  -out tls-vm.crt \
  -subj "/CN=vm-app.example.com" \
  -days 365

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Déployer HAProxy

Installer le contrôleur d'entrée HAProxy et l'équilibreur de charge L4

export HAPROXY_VERSION=3.1.14

# pull the HAProxy Ingress Controller image and push it to Harbor
docker pull haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  --platform linux/amd64
docker tag haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}

# Get Helm repo
helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

# Install the Ingress Controller with helm
helm upgrade --install haproxy-kubernetes-ingress \
  haproxytech/kubernetes-ingress \
  --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml \
  --namespace load-balancer \
  --set controller.image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress \
  --set controller.image.tag=${HAPROXY_VERSION} \
  --set controller.existingImagePullSecret=${IMAGE_PULL_SECRET_NAME} \
  --set controller.service.type=LoadBalancer \
  --set-json \
  controller.service.annotations='{"networking.gke.io/load-balancer-type": "internal"}'

Le contrôleur d'entrée HAProxy obtient une adresse IP virtuelle unique pour l'accès client à l'aide d'un service de type LoadBalancer. Ce service configure un équilibreur de charge de couche 4 entièrement géré. Pour simplifier ce guide, un équilibreur de charge interne est créé en définissant l'annotation load-balancer-type sur internal. Si vous omettez cette annotation, vous obtiendrez un équilibreur de charge externe. Le déploiement Kubernetes extrait de manière sécurisée les images de Harbor à l'aide du secret fourni (${IMAGE_PULL_SECRET_NAME}), qui contient les identifiants du compte robot Harbor.

Valider l'installation du contrôleur d'entrée HAProxy

Vérifiez que les pods du contrôleur d'entrée HAProxy sont en cours d'exécution et prêts :

kk get pods -n load-balancer

Le résultat doit se présenter sous la forme suivante :

NAME                                          READY   STATUS      RESTARTS   AGE
haproxy-kubernetes-ingress-78dc9c8676-f8fcb   1/1     Running     0          35s
haproxy-kubernetes-ingress-78dc9c8676-lfnr2   1/1     Running     0          65s
haproxy-kubernetes-ingress-crdjob-3-tgj2h     0/1     Completed   0          65s

Vérifiez que le service du contrôleur d'entrée HAProxy est créé et configuré :

kk get services -n load-balancer

La sortie ressemble à ceci :

NAME                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                  AGE
haproxy-kubernetes-ingress   LoadBalancer   10.252.27.46   10.252.4.17   80:32023/TCP,443:31103/TCP,443:31103/UDP,1024:30146/TCP,6060:30718/TCP   10m

Définir des ressources d'entrée pour les applications de démonstration

Créez la ressource d'Ingress qui connectera HAProxy au service d'application conteneurisée.

cat << EOF > hello-app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-app-ingress
  namespace: hello-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "k8s-app.example.com"
    secretName: tls-containerized
  rules:
  - host: "k8s-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-app
            port:
              number: 80
EOF

kk apply -f hello-app-ingress.yaml

Créez la ressource d'Ingress qui se connectera au service sans sélecteur de l'application de VM et adressez l'adresse IP de la VM vers laquelle le trafic doit être acheminé.

cat << EOF > vm-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vm-app-ingress
  namespace: vm-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "vm-app.example.com"
    secretName: tls-vm
  rules:
  - host: "vm-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vm-app-svc
            port:
              number: 443
EOF

kk apply -f vm-ingress.yaml

Récupérer l'adresse IP de l'équilibreur de charge

Exécutez la commande pour obtenir l'adresse IP de l'équilibreur de charge.

kk get services/haproxy-kubernetes-ingress \
  -n load-balancer \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Elle sera nécessaire pour vérifier l'accès aux applications. Elle sera appelée LOAD_BALANCER_IP.

Créer une VM cliente

Suivez les étapes pour créer une VM cliente :

Ouvrez la console GDC dans votre navigateur Web.
Ouvrez le menu, puis cliquez sur Machines virtuelles.
Cliquez sur Créer une instance.
Créez une VM nommée client, sélectionnez un petit type de machine, puis sélectionnez Rocky Linux ou Ubuntu, qui sont fournis avec curl préinstallé.
Cliquez sur Créer.
Attendez quelques minutes que la VM soit prête.
Une fois la VM prête, établissez une connexion SSH avec la VM :
1. Dans la console GDC, cliquez sur la VM.
2. Cliquez sur Se connecter avec SSH.

Vérifier l'accès et le routage

Pour tester le routage, exécutez des commandes curl à partir de votre VM cliente. Vous pouvez vous connecter aux deux applications à l'aide de leurs noms d'hôte définis avec l'adresse IP de l'équilibreur de charge.

En transmettant l'option --resolve dans curl, vous pouvez forcer la résolution des noms de domaine en adresse IP de votre équilibreur de charge L4 GDC sous air gap. Notez que nous transmettons l'option -k pour approuver les certificats autosignés.

Testez l'application conteneurisée Kubernetes :

curl -k --resolve k8s-app.example.com:443:$LOAD_BALANCER_IP https://k8s-app.example.com -v

Testez l'application de VM externe :

curl -k --resolve vm-app.example.com:443:$LOAD_BALANCER_IP https://vm-app.example.com -v

Si la configuration est correcte, le contrôleur d'Ingress agira de manière transparente en tant que terminateur TLS et transmettra le trafic à la destination.

Facultatif : Utiliser des certificats prêts pour la production

Cette section explique comment utiliser le service d'autorité de certification GDC sous air gap pour créer une autorité de certification racine privée, émettre des certificats signés pour vos charges de travail et mettre à jour de manière sécurisée votre cluster standard GDC sous air gap et vos VM clientes.

Cette section explique comment utiliser le service d'autorité de certification air-gapped GDC pour créer une autorité de certification racine privée et émettre des certificats valides pour vos applications. En installant cette autorité de certification racine sur votre VM cliente, vous pouvez vérifier que la terminaison TLS fonctionne de manière transparente avec des certificats approuvés, sans avoir à contourner les avertissements SSL (par exemple, à l'aide de curl -k).

Accorder les autorisations nécessaires et obtenir les identifiants

Pour gérer le service d'autorité de certification et émettre des certificats, votre utilisateur doit disposer des rôles IAM appropriés dans le projet.

Accordez les rôles certificate-authority-service-admin et certificate-requester :

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-authority-service-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-requester

Obtenez les identifiants du serveur d'API de gestion :

gdcloud clusters get-credentials ${ORG_NAME}-admin

Créer l'autorité de certification racine

Vous allez créer une autorité de certification dans le serveur d'API de gestion au sein de l'espace de noms de votre projet.

Appliquez la ressource CertificateAuthority :

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  namespace: ${PROJECT_ID}
spec:
  caProfile:
    commonName: "My Root CA"
    duration: 87600h # 10 years
    keyAlgorithm: RSA_2048
    maxChainLength: 1
  caType: ROOT
  keyLocation: HSM
  rotationPolicy:
    cronTime: 0 0 1 1 *
EOF

km -n ${PROJECT_ID} get \
certificateauthority.pki.security.gdc.goog/my-root-ca -ojson \
| jq -r '
.status.conditions[] | select( .type as $id | "Ready" | index($id)) .status'

Émettre et déployer des certificats

Une fois l'autorité de certification prête, vous demanderez des certificats pour l'application conteneurisée et l'application basée sur une VM. Ces requêtes ont lieu dans le serveur d'API de gestion, et les clés résultantes doivent être déplacées vers votre cluster standard.

Créez des requêtes pour les deux domaines :

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-containerized-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "k8s-app.example.com"
      dnsNames:
      - "k8s-app.example.com"
  signedCertificateSecret: tls-containerized-signed
---
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-vm-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "vm-app.example.com"
      dnsNames:
      - "vm-app.example.com"
  signedCertificateSecret: tls-vm-signed
EOF

Attendez quelques instants que les certificats soient émis. Vous pouvez vérifier qu'ils sont prêts lorsque la condition "Ready" (Prêt) est définie sur "True" :

km get certificaterequests -n ${PROJECT_ID}

Mettre à jour le cluster standard

Si vous avez suivi les sections précédentes de ce guide, vous disposez de secrets autosignés dans votre cluster standard. Vous devez les supprimer avant de créer les nouvelles versions signées :

kk delete secret tls-containerized -n load-balancer
kk delete secret tls-vm -n load-balancer

kk delete secret tls-containerized -n hello-app
kk delete secret tls-vm -n vm-app

Extrayez maintenant les certificats signés du serveur d'API de gestion et créez les nouveaux secrets dans le cluster standard.

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-containerized.key

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-vm.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-vm.key

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Les nouveaux secrets seront obtenus et actualisés automatiquement par les équilibreurs de charge.

Configurer l'approbation du client

Pour vérifier la configuration, vous devez indiquer à votre VM cliente d'approuver votre nouvelle autorité de certification racine.

Extrayez le certificat CA racine dans un fichier :

km get secret -n ${PROJECT_ID} my-root-ca-secret \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > my-root-ca.crt

Transférez le certificat vers votre VM cliente. (Vous pouvez copier le contenu de my-root-ca.crt et le coller dans un fichier sur la VM cliente.)

Sur la VM cliente, mettez à jour le magasin de confiance.

Si la VM client est Ubuntu :

sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo chmod 644 /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates

Si la VM client est Rocky Linux :

sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Vérifier l'accès

Vous pouvez désormais accéder à vos applications à l'aide de curl sans l'option -k. La connexion sera entièrement approuvée.

Testez l'application conteneurisée k8s :

curl -v --resolve k8s-app.example.com:443:LOAD_BALANDER_IP https://k8s-app.example.com

Testez l'application de VM :

curl -v --resolve vm.example.com:443:LOAD_BALANDER_IP https://vm-app.example.com

Si l'opération réussit, le résultat de l'application s'affiche immédiatement, sans aucun avertissement de certificat SSL.