Anthos Service Mesh 1.10 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

Installer Anthos Service Mesh sur site avec un HSM et Vault

Ce guide explique comment installer Anthos Service Mesh sur un cluster GKE sur VMware existant, et comment utiliser Thales Luna HSM 7+ et Hashicorp Vault pour générer de manière sécurisée la clé de signature d'autorité de certification d'Istiod et la protéger.

Si une version précédente d'Anthos Service Mesh est installée, consultez la page Mettre à niveau Anthos Service Mesh GKE sur VMware. Cette installation active les fonctionnalités compatibles sur votre cluster.

Avant de commencer

Passez en revue les conditions suivantes avant de commencer la configuration.

Conditions requises

Vous devez disposer d'un abonnement Anthos. Une option de facturation à l'usage est également disponible pour GKE Enterprise sur Google Cloud uniquement. Pour en savoir plus, consultez le guide des tarifs de GKE Enterprise.
Vous devez contacter l'équipe d'assistance pour vous accorder les autorisations permettant d'accéder aux images. L'équipe d'assistance vous fournira également une assistance supplémentaire.
Vérifiez que le cluster dans lequel vous installez Anthos Service Mesh dispose d'au moins quatre processeurs virtuels, 15 Go de mémoire et quatre nœuds.
Vous devez nommer vos ports de service à l'aide de la syntaxe suivante : name: protocol[-suffix] où les crochets indiquent un suffixe facultatif qui doit commencer par un tiret. Pour plus d'informations, consultez la section Nommer les ports de service.
Vérifiez que la version de votre cluster est répertoriée dans la section Environnements compatibles. Pour vérifier la version de votre cluster, vous pouvez utiliser l'outil de ligne de commande gkectl. Si vous n'avez pas installé gkectl, consultez la page Téléchargements de GKE On-Prem.
```
gkectl version
```
Vous devez disposer de Thales Luna HSM 7+ dans votre infrastructure. Le HSM doit avoir le service réseau configuré et accessible depuis le cluster Anthos Service Mesh.
Vous devez disposer des serveurs Hashicorp Vault dans votre infrastructure pour stocker les identifiants permettant d'accéder au HSM. Les serveurs Vault doivent être accessibles à partir du cluster Anthos Service Mesh via le réseau.

Configurer votre environnement

Installez les outils suivants sur la machine depuis laquelle vous contrôlez le processus d'installation d'Anthos Service Mesh.

Outil de ligne de commande curl
Google Cloud CLI.

Après avoir installé les outils prérequis, procédez comme suit :

Authentifiez-vous à l'aide de la CLI gcloud :
```
gcloud auth login --project PROJECT_ID
```
Mettez à jour les composants :
```
gcloud components update
```
Installez kubectl :
```
gcloud components install kubectl
```
Pour déployer et tester votre installation avec l'exemple d'application Online Boutique, installez kpt :
```
gcloud components install kpt
```
Basculez le contexte vers votre cluster d'utilisateur (si nécessaire) :
```
kubectl config use-context CLUSTER_NAME
```
Accordez des autorisations d'administrateur de cluster à votre compte utilisateur (votre adresse e-mail de connexion Google Cloud). Vous avez besoin de ces autorisations pour créer les règles de contrôle d'accès basé sur les rôles (RBAC) nécessaires pour Anthos Service Mesh :
```
kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=USER_ACCOUNT
```

Déployer des dépendances

Déployez Thales Luna HSM 7+ dans votre infrastructure pour gérer en toute sécurité les clés de signature CA d'Istio. Assurez-vous que le HSM dispose d'un service réseau et d'une connectivité avec le cluster Anthos Service Mesh.
Déployer les serveurs Hashicorp Vault dans votre infrastructure pour stocker les identifiants permettant d'accéder au HSM. Assurez-vous que les serveurs Vault disposent d'une connectivité réseau avec le cluster Anthos Service Mesh.
Vous devez disposer d'un poste de travail ayant accès au serveur Vault, au HSM et au cluster Kubernetes sur lequel vous installez Anthos Service Mesh.

Configurer le module de sécurité matérielle (HSM)

Cette section répertorie les étapes à suivre pour configurer le module de sécurité matérielle (HSM) et générer des clés de chiffrement.

Provisionner les identifiants et l'emplacement HSM

Suivez le Guide d'installation de HSM pour effectuer les étapes suivantes.

Configurez le module HSM en tant que HSM réseau.
Provisionnez des fichiers PEM pour les connexions mTLS avec le HSM, y compris un fichier de clé client, un fichier de certificat client et un fichier de certificat de serveur.
Provisionnez un emplacement HSM pour Anthos Service Mesh, puis enregistrez l'étiquette d'emplacement et le code PIN.

Générer une clé de chiffrement de clé HSM (KEK)

Sur la machine ayant accès au HSM, téléchargez l'outil HSM (disponible uniquement pour Linux amd-64).
```
gsutil cp gs://artifacts.thalescpl-io-k8s-kms-plugin.appspot.com/binary/k8s-kms-plugin .
```

Définissez des variables d'environnement avant d'exécuter l'outil HSM en tant que serveur local. Celui-ci se connecte au HSM et fonctionne sur le socket de domaine Unix local (UDS).

export P11_TOKEN=HSM slot label
export ChrystokiConfigurationPath=path to the Thales HSM Chrystoki configuration file
export P11_LIB=path to the libCryptoki2.so file for accessing the Thales HSM
export P11_PIN_FILE=path to the file that stores the HSM slot PIN
export SOCKET=/tmp/.hsm-sock
./k8s-kms-plugin serve &

Un résultat semblable aux lignes suivantes doit s'afficher :

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /home/hsm/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/.hsm-sock  line="cmd/serve.go:119"
INFO Serving on socket: /tmp/.hsm-sock  line="cmd/serve.go:198"

Si vous ne possédez pas de clé de chiffrement de clé (KEK) sur le HSM, suivez les étapes ci-dessous pour en générer une. Utilisez k8s-kms-plugin en tant que client pour communiquer avec le serveur d'outils HSM. Si vous souhaitez spécifier explicitement un ID KEK, vous pouvez transmettre l'option --kek-id dans la commande. Sinon, un ID KEK aléatoire sera généré automatiquement.
```
./k8s-kms-plugin generate-kek --kek-id KEK ID
```
Enregistrez l'ID de la KEK. Vous l'utiliserez dans les étapes suivantes.
HSM utilise le certificat racine importé pour valider le certificat CA signé. Vous pouvez suivre cette étape pour importer le certificat racine dans HSM. Utilisez k8s-kms-plugin comme client pour communiquer avec le serveur d'outils HSM. Importez le certificat racine à l'aide de la commande suivante.
```
./k8s-kms-plugin import-ca -f root cert PEM file
```

Configurer l'authentification Kubernetes pour Vault

Dans le cluster Kubernetes, créez un compte de service dédié et une stratégie RBAC pour Vault afin d'appeler l'API TokenReview. Créez un espace de noms dédié à cette fin.
Créez le compte de service par défaut dans l'espace de noms vault, définissez les autorisations, puis extrayez le jeton Web JSON (JWT) associé pour que le serveur Vault appelle l'API Kubernetes TokenReview. Remarque : Vous pouvez utiliser n'importe quel compte de service et espace de noms Kubernetes s'ils disposent des autorisations suffisantes.
Configurez le suffixe de cluster pour le cluster que vous souhaitez configurer. Utilisez un répertoire dédié pour la configuration.
```
export CLUSTER_SUFFIX="c1"
mkdir ${CLUSTER_SUFFIX}
cd ${CLUSTER_SUFFIX}
```
Basculez vers le cluster que vous souhaitez gérer et créez l'espace de noms vault. kubectl crée automatiquement le compte de service par défaut.
```
kubectl create ns vault
```

Pour accorder des autorisations, associez le compte de service default.vault au rôle auth-delegator.

kubectl apply -f -<< EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: role-tokenreview-binding
 namespace: vault
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
 - kind: ServiceAccount
   name: default
   namespace: vault
EOF

Créez un secret contenant les identifiants du jeton.

VAULT_SA_SECRET=default-token
kubectl apply -n vault -f - << EOF
apiVersion: v1
kind: Secret
metadata:
 name: "${VAULT_SA_SECRET}"
 annotations:
   kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Obtenez le jeton JWT pour le compte de service default.vault.

VAULT_SA_JWT_TOKEN=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data.token}" | base64 --decode)
echo $VAULT_SA_JWT_TOKEN > ${CLUSTER_SUFFIX}-tokenreview_jwt
cat ${CLUSTER_SUFFIX}-tokenreview_jwt

Récupérez l'adresse et le certificat CA du serveur d'API Kubernetes. Configurez ensuite le serveur Vault pour qu'il appelle le serveur d'API Kubernetes.

Récupérez les valeurs IP:Port publiques de Kubernetes.

K8S_ADDR=$(kubectl config  view -o jsonpath="{.clusters[?(@.name == '$(kubectl config current-context)')].cluster.server}")
echo $K8S_ADDR > ${CLUSTER_SUFFIX}-k8s_addr
cat ${CLUSTER_SUFFIX}-k8s_addr

Obtenez le certificat pour authentifier le serveur d'API Kubernetes.

VAULT_SA_CA_CRT=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data['ca\.crt']}" | base64 --decode)
echo $VAULT_SA_CA_CRT > "${CLUSTER_SUFFIX}-k8s_cert"
cat "${CLUSTER_SUFFIX}-k8s_cert"

Convertissez le fichier de certificat au format PEM et validez-le.

sed -i 's/ CERTIFICATE/CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/ /\n/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/CERTIFICATE/ CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert

Vérifiez que le certificat est valide.

openssl x509 -in ${CLUSTER_SUFFIX}-k8s_cert -noout -text

Revenez au répertoire précédent.
```
cd ..
```

Configurez maintenant Vault à l'étape suivante à l'aide des trois fichiers du répertoire du cluster.

Configurer Vault pour stocker les identifiants HSM

Lorsque le serveur Vault diffuse le trafic TLS avec un certificat valide, configurez la PKI de Vault et configurez l'authentification Kubernetes. Vous trouverez ci-dessous un exemple pour configurer une autorité de certification racine unique et des autorités de certification intermédiaires par cluster.

Connectez-vous à Vault en mode racine.
```
vault login
```

Stockez le secret pour HSM.

SECRET_PATH=asm-$CLUSTER_SUFFIX
vault secrets enable -path=$SECRET_PATH  kv
vault secrets tune -max-lease-ttl=87600h $SECRET_PATH
export HSM_SECRET_PATH="$SECRET_PATH/hsm"
vault kv put ${HSM_SECRET_PATH} clientcert=HSM_CLIENT_CERT clientkey=HSM_CLIENT_KEY servercert=HSM_SERVER_CERT PIN=HSM_PIN
vault kv get ${HSM_SECRET_PATH}

Créez une stratégie avec des autorisations sur le chemin PKI.

vault policy write asm-$CLUSTER_SUFFIX-hsm-policy -<< EOF
path "${HSM_SECRET_PATH}" {
capabilities = ["read"]
}
EOF

Ajoutez l'authentification Kubernetes pour le cluster.

vault auth enable --path="${HSM_SECRET_PATH}"  kubernetes

Définissez le JWT Kubernetes, l'adresse Kubernetes et le certificat CA Kubernetes dans le chemin d'authentification Vault.

vault write auth/${HSM_SECRET_PATH}/config \
token_reviewer_jwt=cat "${CLUSTER_SUFFIX}"-tokenreview_jwt \
kubernetes_host=cat "${CLUSTER_SUFFIX}"-k8s_addr \
kubernetes_ca_cert=@"${CLUSTER_SUFFIX}"-k8s_cert

Autorisez istiod-service-account.istio-system à s'authentifier en tant que rôle demo et utilisez la règle créée.

vault write auth/${HSM_SECRET_PATH}/role/istiod \
bound_service_account_names=istiod-service-account \
bound_service_account_namespaces=istio-system \
policies=asm-$CLUSTER_SUFFIX-hsm-policy \
ttl=768h

Revenez au dossier parent.
```
cd ..
```

Télécharger le fichier d'installation

Linux

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz
```

Téléchargez le fichier de signature et utilisez openssl pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig istio-1.10.6-asm.2-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Le résultat attendu est Verified OK.

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
```
 tar xzf istio-1.10.6-asm.2-linux-amd64.tar.gz
```
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.10.6-asm.2, qui contient les éléments suivants :
- Des exemples d'applications dans le répertoire samples
- L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
```
cd istio-1.10.6-asm.2
```

macOS

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz
```

Téléchargez le fichier de signature et utilisez openssl pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.10.6-asm.2-osx.tar.gz.1.sig istio-1.10.6-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Le résultat attendu est Verified OK.

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
```
tar xzf istio-1.10.6-asm.2-osx.tar.gz
```
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.10.6-asm.2, qui contient les éléments suivants :
- Des exemples d'applications dans le répertoire samples
- L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
```
cd istio-1.10.6-asm.2
```

Windows

Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip
```

Téléchargez le fichier de signature et utilisez openssl pour valider la signature :

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.10.6-asm.2-win.zip.1.sig istio-1.10.6-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Le résultat attendu est Verified OK.

Extrayez le contenu du fichier vers n'importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
```
tar xzf istio-1.10.6-asm.2-win.zip
```
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.10.6-asm.2, qui contient les éléments suivants :
- Des exemples d'applications dans le répertoire samples
- L'outil de ligne de commande istioctl que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoire bin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
```
cd istio-1.10.6-asm.2
```

Configurer la ressource dans le plan de contrôle

Définissez les variables d'environnement.

export CLUSTER_SUFFIX="c1"
export VAULT_ADDR="https://VAULT_IP:PORT"

Copiez le fichier contenant le certificat pour authentifier Vault dans un fichier nommé cert. Par exemple, le certificat TLS du serveur Vault, ${VAULT_CACERT}.

Remarque : Le client Vault utilise ce certificat pour authentifier le serveur Vault. Ce certificat est différent du certificat utilisé par Vault pour authentifier le serveur d'API Kubernetes.
```
cp ${VAULT_CACERT} ./cert
```

Créez une ressource ConfigMap à partir du fichier dans l'espace de noms istio-system.

kubectl create ns istio-system
kubectl delete configmap vault-tls-cert -n istio-system
kubectl create configmap vault-tls-cert -n istio-system --from-file=./cert

Configurer le webhook de validation

Lorsque vous installez Anthos Service Mesh, vous définissez un libellé de révision sur istiod. Vous devez définir la même révision sur le webhook de validation.

Copiez le fichier YAML suivant dans un fichier appelé istiod-service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1106-2
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1106-2

Installer Anthos Service Mesh

Configurez les variables d'environnement pour configurer ASM de sorte qu'il interagisse avec Vault et HSM. La commande suivante réduit le délai d'attente à 10 secondes, car Istio ne sera pas complètement prêt en raison de la mise en attente de l'opération d'importation par l'opérateur.

export HSM_SLOT_LABEL=the HSM slot label
export VAULT_ADDR=address of the vault server
export HSM_SECRET_PATH=the path to the HSM secret on Vault
export KEK_ID=the HSM slot KEK ID
export HSM_PLUGIN_IMAGE=gcr.io/thalescpl-io-k8s-kms-plugin/hsm-plugin:asm-1.7-1
export VAULT_CLIENT_IMAGE=gcr.io/gke-release/asm/vaultclient:latest
export WAIT_FOR_RESOURCES_TIMEOUT=10s

Exécutez la commande suivante pour installer Anthos Service Mesh à l'aide du profil asm-multicloud. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez -f et le nom de fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.

istioctl install --set profile=asm-multicloud \
   --set revision=asm-1106-2 \
   --set values.hsm.enabled=true \
   --set values.hsm.hsmKEKID=${KEK_ID} \
   --set values.hsm.hsmPluginImage=${HSM_PLUGIN_IMAGE} \
   --set values.hsm.hsmSlotLabel=${HSM_SLOT_LABEL} \
   --set values.hsm.vaultClientImage=${VAULT_CLIENT_IMAGE} \
   --set values.hsm.vaultAddr=${VAULT_ADDR} \
   --set values.hsm.vaultAuthPath=auth/${HSM_SECRET_PATH}/login \
   --set values.hsm.vaultAuthRole=istiod \
   --set values.hsm.vaultAuthJwtPath="/var/run/secrets/kubernetes.io/serviceaccount/token" \
   --set values.hsm.vaultSecretPath=${HSM_SECRET_PATH} \
   --set values.global.jwtPolicy="first-party-jwt"

Configurez le webhook de validation de sorte qu'il puisse localiser le service istiod avec le libellé de révision :
```
kubectl apply -f istiod-service.yaml
```
Cette commande crée une entrée de service qui permet au webhook de validation de vérifier automatiquement les configurations avant leur application.
Vérifiez que l'Istiod est initialisée correctement et en attente.
```
kubectl get pod -l app=istiod -n istio-system
```
Le résultat est semblable à ce qui suit :
```
NAME                      READY   STATUS    RESTARTS   AGE
istiod-66ff56d76c-f9p5l   2/3     Running   2          1m27s
```
Notez qu'Istiod n'est pas complètement prêt, car le conteneur discovery est bloqué et en attente du certificat.

Consultez le journal des conteneurs Istiod pour vous assurer que leur état est correct.

kubectl logs -c hsm-plugin -l app=istiod -n istio-system

Le résultat est semblable à ce qui suit :

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /var/run/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/run/hsm-socket/.sock  line="cmd/serve.go:119"
INFO Serving on socket: /var/run/hsm-socket/.sock  line="cmd/serve.go:198"
KEK ID: 7651a4ea-eeb7-4c1f-927b-8c871c2127aa

kubectl logs -c discovery -l app=istiod -n istio-system

La dernière ligne de sortie devrait se présenter comme suit :

...
2020-10-15T21:56:56.918931Z info    pkica   Wait until the CA certificate secret istio-system.istio-ca-cert can be loaded...

Signer le certificat pour Istiod

Téléchargez le fichier CSR chiffré à partir du secret Kubernetes.

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json

Déchiffrer la requête de signature de certificat.

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json
./k8s-kms-plugin decrypt-csr -f encrypted_csr.json -o csr.pem

L'administrateur de sécurité doit prendre le fichier csr.pem et le signer en utilisant l'autorité de certification racine.
Placez votre chaîne de certificats à la racine du fichier nommé cert-chain.pem, puis exécutez la commande suivante.
```
kubectl create secret generic istio-ca-cert --from-file=cert-chain.pem -n istio-system
```

Vérifiez que Istiod charge la nouvelle chaîne de certificats en inspectant le journal Istiod.

kubectl logs ISTIOD_POD -c discovery -n istio-system | grep "CA cert\:" -A 60

Le résultat devrait être semblable à ce qui suit :

2020-10-24T18:58:14.354254Z info pkica CA cert: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

certificats intermédiaires : -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

certificats racines : -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

Vérifiez l'installation

Procédez comme suit pour vérifier que votre installation Anthos Service Mesh fonctionne correctement.

Vérifier les composants du plan de contrôle

Vérifiez que les pods du plan de contrôle dans istio-system sont opérationnels :

kubectl get pod -n istio-system

Le résultat attendu ressemble à ce qui suit :

NAME                                      READY   STATUS      RESTARTS   AGE
istio-ingressgateway-74cc894bfd-786rg     1/1     Running     0          7m19s
istiod-78cdbbbdb-d7tps                    3/3     Running     0          7m36s
promsd-576b8db4d6-lqf64                   2/2     Running     1          7m19s

Déclenchez un appel TLS à un service à partir du side-car et inspectez le certificat utilisé par le service, en utilisant bookinfo comme exemple.
```
kubectl exec POD -c istio-proxy -- openssl s_client -alpn istio -showcerts -connect details:9080
```
Inspectez les certificats dans la sortie et attendez-vous à voir la chaîne de certificats côté serveur dans le résultat.

Injecter des proxys side-car

Anthos Service Mesh utilise des proxys side-car pour améliorer la sécurité, la fiabilité et l'observabilité du réseau. Avec Anthos Service Mesh, ces fonctions sont extraites du conteneur principal de l'application et mises en œuvre dans un proxy commun hors processus fourni par un conteneur séparé dans le même pod.

L'installation n'est terminée qu'une fois que vous avez activé l'injection automatique du proxy side-car (injection automatique) et que vous avez redémarré les pods de toutes les charges de travail exécutées sur votre cluster avant d'avoir installé Anthos Service Mesh.

Pour activer l'injection automatique, vous devez étiqueter vos espaces de noms avec le même libellé de révision que vous avez défini sur istiod lors de l'installation d'Anthos Service Mesh. Le libellé de révision est utilisé par le webhook d'injecteur side-car pour associer les side-cars injectés à une révision istiod particulière. Après avoir ajouté le libellé, tous les pods existants dans l'espace de noms doivent être redémarrés pour que les side-cars soient injectés.

Avant de déployer de nouvelles charges de travail dans un espace de noms que vous venez de créer, veillez à configurer l'injection automatique afin qu'Anthos Service Mesh puisse surveiller et sécuriser le trafic.

Pour activer l'injection automatique, procédez comme suit :

Exécutez la commande suivante pour localiser le libellé de révision sur istiod :

kubectl -n istio-system get pods -l app=istiod --show-labels

La sortie ressemble à ceci :

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-1106-2.

Appliquez le libellé de révision et supprimez le libellé istio-injection s'il existe. Dans la commande suivante, NAMESPACE est le nom de l'espace de noms dans lequel vous souhaitez activer l'injection automatique, et REVISION est le libellé de révision noté à l'étape précédente.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Vous pouvez ignorer le message "istio-injection not found" dans le résultat. Cela signifie que l'espace de noms ne portait pas précédemment le libellé istio-injection, auquel on s'attend dans de nouvelles installations d'Anthos Service Mesh ou de nouveaux déploiements. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
Si les charges de travail étaient en cours d'exécution sur votre cluster avant d'installer Anthos Service Mesh, redémarrez les pods pour déclencher une réinjection.

La méthode de redémarrage des pods dépend de votre application et de l'environnement dans lequel se trouve le cluster. Par exemple, dans votre environnement de préproduction, vous pouvez simplement supprimer tous les pods, ce qui entraîne leur redémarrage. Toutefois, dans votre environnement de production, vous pouvez peut-être mettre en œuvre un déploiement bleu-vert afin de pouvoir redémarrer des pods en toute sécurité pour éviter l'interruption du trafic.

Vous pouvez exécuter kubectl pour effectuer un redémarrage progressif :
```
kubectl rollout restart deployment -n NAMESPACE
```
Vérifiez que vos pods sont configurés pour pointer vers la nouvelle version de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```

Configurer une adresse IP externe

L'installation d'Anthos Service Mesh par défaut suppose qu'une adresse IP externe est automatiquement allouée aux services LoadBalancer. Ce n'est pas le cas dans GKE sur VMware. Par conséquent, vous devez allouer une adresse IP manuellement pour la ressource de passerelle d'entrée d'Anthos Service Mesh.

Pour configurer une adresse IP externe, suivez les instructions de l'une des sections ci-dessous, en fonction du mode d'équilibrage de charge de votre cluster :

Configurer le mode d'équilibrage de charge intégré

Ouvrez la configuration du service istio-ingressgateway :
```
kubectl edit svc -n istio-system istio-ingressgateway
```
La configuration du service istio-ingressgateway s'ouvre dans l'éditeur de texte par défaut de votre interface système.

Ajoutez la ligne suivante au fichier sous le bloc de spécification (spec) :

loadBalancerIP: <your static external IP address>

Exemple :

spec:
 loadBalancerIP: 203.0.113.1

Enregistrez le fichier.

Configurer le mode d'équilibrage de charge manuel

Pour exposer un service de type NodePort avec une adresse IP virtuelle (VIP) sur votre équilibreur de charge, commencez par obtenir les valeurs nodePort :

Affichez la configuration du service istio-ingressgateway dans votre interface système :

kubectl get svc -n istio-system istio-ingressgateway -o yaml

Chacun des ports des passerelles d'Anthos Service Mesh est affiché. Le résultat ressemble à ce qui suit :

 ...
 ports:
 - name: status-port
   nodePort: 30391
   port: 15020
   protocol: TCP
   targetPort: 15020
 - name: http2
   nodePort: 31380
   port: 80
   protocol: TCP
   targetPort: 80
 - name: https
   nodePort: 31390
   port: 443
   protocol: TCP
   targetPort: 443
 - name: tcp
   nodePort: 31400
   port: 31400
   protocol: TCP
   targetPort: 31400
 - name: https-kiali
   nodePort: 31073
   port: 15029
   protocol: TCP
   targetPort: 15029
 - name: https-prometheus
   nodePort: 30253
   port: 15030
   protocol: TCP
   targetPort: 15030
 - name: https-grafana
   nodePort: 30050
   port: 15031
   protocol: TCP
   targetPort: 15031
 - name: https-tracing
   nodePort: 31204
   port: 15032
   protocol: TCP
   targetPort: 15032
 - name: tls
   nodePort: 30158
   port: 15443
   protocol: TCP
   targetPort: 15443
 ...

Accordez l'accès à ces ports via votre équilibreur de charge.

Par exemple, le port de service http2 utilise le port 80 et le nodePort 31380. Supposons que les adresses des nœuds de votre cluster d'utilisateur soient 192.168.0.10, 192.168.0.11 et 192.168.0.12, et que l'adresse IP virtuelle de votre équilibreur de charges soit 203.0.113.1.

Configurez votre équilibreur de charge de sorte que le trafic dirigé vers 203.0.113.1:80 soit transféré vers 192.168.0.10:31380, 192.168.0.11:31380 ou 192.168.0.12:31380. Vous pouvez sélectionner les ports de service auxquels vous souhaitez donner l'accès à cette adresse IP virtuelle.

Étape suivante

Déployer l'exemple d'application Boutique en ligne