Vous consultez la documentation de l'ancienne version de Service Mesh v1.18.

Versions disponibles

Cloud Service Mesh
Archive 1.22
Archive 1.21
Archive 1.20
Archive 1.19
Archive 1.18

Cette page a été traduite par l'API Cloud Translation.

Renforcer la sécurité de votre application avec Cloud Service Mesh, Config Sync et Policy Controller

Ce tutoriel vous explique comment améliorer le niveau de sécurité de votre cluster et de votre application. Imaginez que vous êtes un administrateur de plate-forme dont l'organisation gère les applications pour leur boutique en ligne avec Cloud Service Mesh, suite d'outils qui vous aide à surveiller et à gérer un maillage de services fiable. Vous devez vous assurer que votre maillage et vos applications sont sécurisés.

Vous pouvez empêcher les erreurs de configuration et valider automatiquement votre maillage de services Cloud Service des stratégies à l'aide de Policy Controller et Config Sync : Policy Controller permet d'appliquer des règles entièrement programmables pour vos clusters. Policy Controller est également fourni avec une bibliothèque par défaut de modèles de contrainte que vous pouvez utiliser avec le lot de règles de sécurité Cloud Service Mesh pour auditer la conformité des failles et des bonnes pratiques de sécurité de votre maillage. Config Sync rapproche en permanence l'état des clusters d'un ensemble central de fichiers de configuration déclaratifs Kubernetes. L'utilisation conjointe de Policy Controller et de Config Sync vous permet d'appliquer en permanence des contraintes à vos configurations de règles Cloud Service Mesh.

Le schéma suivant montre comment Cloud Service Mesh, Policy Controller et Config Sync interagissent dans ce tutoriel pour gérer et protéger une passerelle d'entrée et les exemples d'applications de boutique en ligne que vous utilisez dans ce tutoriel :

Schéma illustrant l'architecture que vous allez créer pour ce tutoriel

Objectifs

Créer un cluster Google Kubernetes Engine (GKE) et l'enregistrer dans un parc.
Installer Policy Controller, Config Sync et Cloud Service Mesh sur un cluster
Configurez Config Sync pour synchroniser plusieurs dépôts.
Appliquer les bonnes pratiques pour déployer des configurations, des applications et des ressources Istio avec Config Sync
Déployer des configurations de cluster, les exemples d'applications de boutique en ligne et une passerelle d'entrée avec Config Sync
Tirez parti des Lot de règles Cloud Service Mesh de Policy Controller pour appliquer les bonnes pratiques de sécurité suivantes:
- S'assurer que toutes les charges de travail du maillage ont une injection side-car automatique.
- Appliquer le chiffrement sur l'ensemble du trafic dans le maillage.
- S'assurer que toutes les charges de travail du maillage disposent d'un contrôle d'accès précis.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

GKE.
GKE Enterprise. The billing for GKE Enterprise includes billing for the Cloud Service Mesh, Config Sync, and Policy Controller.

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.

Préparer votre environnement

Dans cette section, vous allez préparer votre environnement afin de pouvoir installer Cloud Service Mesh, Policy Controller et Config Sync :

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Passez à la dernière version de Google Cloud CLI :
```
gcloud components update
```
Pour stocker les fichiers que vous créez dans ce tutoriel, créez un répertoire :
```
mkdir ~/asm-acm-tutorial-dir
```
Pour simplifier le reste du tutoriel, créez les variables d'environnement suivantes :
```
PROJECT_ID=PROJECT_ID
gcloud config set project $PROJECT_ID
CLUSTER=asm-acm-tutorial
CLUSTER_ZONE=us-east4-a
MEMBERSHIP=asm-acm-tutorial
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')
```
Remplacez PROJECT_ID par l'ID de projet que vous souhaitez utiliser pour ce tutoriel.

Si vous êtes invité à autoriser Cloud Shell, cliquez sur Autoriser pour terminer l'opération.

Activez les API dont vous avez besoin pour ce tutoriel :

gcloud

gcloud services enable \
    mesh.googleapis.com \
    anthos.googleapis.com

Config Connector

Ce tutoriel inclut les ressources de Config Connector. Vous pouvez utiliser ces ressources pour effectuer les mêmes tâches que celles effectuées dans l'onglet gcloud. Pour utiliser ces ressources, installez Config Connector et appliquez-les de la manière la plus adaptée à votre environnement.

Utilisez le fichier manifeste Services suivant :

apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: mesh.googleapis.com
spec:
  resourceID: mesh.googleapis.com
  projectRef:
    external: PROJECT_ID
---
apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: anthos.googleapis.com
spec:
  resourceID: anthos.googleapis.com
  projectRef:
    external: PROJECT_ID

Cette opération peut prendre plus d'une minute.

Configurer un cluster GKE

Dans cette section, vous allez créer un cluster GKE, puis l'enregistrer dans un parc. Un parc est un concept Google Cloud qui permet d'organiser logiquement des clusters et d'autres ressources. Il vous permet d'utiliser et de gérer des fonctionnalités multicluster, ainsi que d'appliquer des règles cohérentes à vos systèmes.

Le cluster que vous créez dans cette section est celui que vous installez Cloud Service Mesh, Policy Controller et Config Sync activés. Il s'agit également du cluster dans lequel vous déployez les exemples d'applications Online Boutique.

Pour configurer votre cluster, procédez comme suit :

Créez un cluster GKE :

gcloud

gcloud container clusters create ${CLUSTER} \
    --zone ${CLUSTER_ZONE} \
    --machine-type=e2-standard-4 \
    --num-nodes 4 \
    --workload-pool ${PROJECT_ID}.svc.id.goog \
    --labels mesh_id=proj-${PROJECT_NUMBER}

Config Connector

Utilisez les fichiers manifestes ContainerCluster et ContainerNodePool suivants :

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: asm-acm-tutorial
spec:
  clusterRef:
    name: asm-acm-tutorial
  location: us-east4-a
  nodeConfig:
    machineType: e2-standard-4
  nodeCount: 4
---
apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
    cnrm.cloud.google.com/remove-default-node-pool: "true"
  labels:
    mesh_id: proj-PROJECT_NUMBER
  name: asm-acm-tutorial
spec:
  location: us-east4-a
  initialNodeCount: 1
  workloadIdentityConfig:
    workloadPool: PROJECT_ID.svc.id.goog

Remplacez PROJECT_NUMBER par la valeur de l'environnement PROJECT_NUMBER. récupérée précédemment.

Cette opération peut prendre plus de cinq minutes.

Pour vous assurer que le cluster GKE a bien été créé, décrivez son état :

gcloud container clusters list \
    --zone ${CLUSTER_ZONE} \
    --project ${PROJECT_ID}

Le résultat ressemble à ce qui suit :

NAME                LOCATION      MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
asm-acm-tutorial    us-east4-a    1.23.12-gke.100  35.186.179.30  e2-standard-4  1.23.12-gke.100  3          RUNNING

Connectez-vous au cluster GKE :

gcloud container clusters get-credentials ${CLUSTER} \
    --zone ${CLUSTER_ZONE} \
    --project ${PROJECT_ID}

Enregistrez votre cluster dans un parc :

gcloud

gcloud container fleet memberships register ${MEMBERSHIP} \
    --project ${PROJECT_ID} \
    --gke-cluster ${CLUSTER_ZONE}/${CLUSTER} \
    --enable-workload-identity

Le résultat ressemble à ce qui suit :

kubeconfig entry generated for asm-acm-tutorial.
Waiting for membership to be created...done.
Created a new membership [projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial] for the cluster [asm-acm-tutorial]
Generating the Connect Agent manifest...
Deploying the Connect Agent on cluster [asm-acm-tutorial] in namespace [gke-connect]...
Deployed the Connect Agent on cluster [asm-acm-tutorial] in namespace [gke-connect].
Finished registering the cluster [asm-acm-tutorial] with the Fleet.

Config Connector

Utilisez le fichier manifeste GKEHubMembership suivant :

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubMembership
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: asm-acm-tutorial
spec:
  location: global
  authority:
    issuer: https://container.googleapis.com/v1/projects/PROJECT_ID/locations/us-east4-a/clusters/asm-acm-tutorial
  endpoint:
    gkeCluster:
      resourceRef:
        name: asm-acm-tutorial

Pour vous assurer que le cluster GKE est bien enregistré, décrivez son état :

gcloud container fleet memberships list

Le résultat ressemble à ce qui suit :

NAME              EXTERNAL_ID                           LOCATION
asm-acm-tutorial  0e12258c-8831-4d81-b5c0-5e7099a468cc  global

Explorer les dépôts

Dans la section d'installation suivante, vous allez appliquer un le fichier manifeste acm-config.yaml. Ce fichier manifeste configure votre cluster pour qu'il effectue la synchronisation à partir du dossier asm-acm-tutorial de l'exemple de dépôt. Ce dossier contient tous les fichiers de configuration dont vous avez besoin pour effectuer le reste du tutoriel.

Pour simplifier ce tutoriel, exécutez les commandes sed afin de mettre à jour le fichier acm-config.yaml. Avec le fichier acm-config.yaml, Config Sync déploie les fichiers manifestes requis pour chaque étape de ce tutoriel. La mise à jour d'un seul fichier vous permet de vous concentrer sur les concepts et le flux de sécurisation de vos clusters, maillages et applications, sans avoir à manipuler les fichiers et à exécuter des commandes git de manière répétée.

Pour utiliser la capacité de Config Sync à synchroniser plusieurs dépôts, utilisez les ressources suivantes :

root-sync, en tant que dépôt RootSync, contient toutes les configurations de votre cluster, y compris RepoSyncs, Constraints, ClusterRole et RoleBindings, ainsi que les ressources incluses dans certains espaces de noms système tels que istio-system.
ingress-gateway, en tant que premier RepoSync, contient toutes les ressources nécessaires pour déployer une passerelle d'entrée et la sécuriser progressivement tout au long de ce tutoriel.
online-boutique, en tant que deuxième RepoSync, contient toutes les ressources nécessaires pour déployer les applications de boutique en ligne et les sécuriser progressivement tout au long de ce tutoriel.

Installer Policy Controller, Config Sync et Cloud Service Mesh géré

Maintenant que vous avez créé et enregistré votre cluster, vous pouvez installer Config Sync, Policy Controller et Cloud Service Mesh sur votre cluster, puis le configurer pour qu'il effectue la synchronisation à partir des configurations du dépôt RootSync par défaut :

Activer l'opérateur ConfigManagement, qui gère Config Sync et Policy Controller:

gcloud

gcloud beta container fleet config-management enable

Config Connector

Utilisez le fichier manifeste GKEHubFeature suivant :

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeature
metadata:
  name: configmanagement
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  resourceID: configmanagement

Activez Cloud Service Mesh dans votre parc.

gcloud

gcloud container fleet mesh enable

Config Connector

Utilisez le fichier manifeste GKEHubFeature suivant :

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeature
metadata:
  name: servicemesh
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  resourceID: servicemesh

Activez la gestion automatique de Cloud Service Mesh pour permettre à Google d'appliquer la configuration recommandée de Cloud Service Mesh géré :

gcloud

gcloud container fleet mesh update \
    --management automatic \
    --memberships ${MEMBERSHIP}

Config Connector

Utilisez le fichier manifeste GKEHubFeatureMembership suivant :

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeatureMembership
metadata:
  name: servicemesh-membership
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  membershipRef:
    name: asm-acm-tutorial
  featureRef:
    name: servicemesh
  mesh:
    management: MANAGEMENT_AUTOMATIC

Activez Config Sync et Policy Controller :

gcloud

Enregistrez le fichier manifeste suivant sous le nom acm-config.yaml dans le répertoire ~/asm-acm-tutorial-dir:

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    policyDir: asm-acm-tutorial/root-sync/init
    secretType: none
    sourceFormat: unstructured
    syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    syncBranch: main
  policyController:
    enabled: true
    referentialRulesEnabled: true
    templateLibraryInstalled: true

Pour en savoir plus sur les champs de configuration de la Google Cloud CLI, consultez la page Champs spécifiques de la commande d'application de gcloud.

Appliquez le fichier :

gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

Config Connector

Utilisez le fichier manifeste GKEHubFeatureMembership suivant :

apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeatureMembership
metadata:
  name: configmanagement-membership
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  membershipRef:
    name: asm-acm-tutorial
  featureRef:
    name: configmanagement
  configmanagement:
    configSync:
      sourceFormat: unstructured
      git:
        policyDir: asm-acm-tutorial/root-sync/init
        secretType: none
        syncBranch: main
        syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    policyController:
      enabled: true
      referentialRulesEnabled: true
      templateLibraryInstalled: true

Policy Controller et Config Sync sont installés sur votre cluster. Ensuite, Config Sync commence à synchroniser toutes les configurations du dépôt RootSync par défaut avec votre cluster. Ces configurations installent et configurent les composants clés suivants :

Les objets RepoSync qui configurent les applications de boutique en ligne et la passerelle d'entrée sont synchronisés :

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
spec:
  override:
    enableShellInRendering: true
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    revision: HEAD
    branch: main
    dir: asm-acm-tutorial/online-boutique/init
    auth: none

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
spec:
  override:
    enableShellInRendering: true
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    revision: HEAD
    branch: main
    dir: asm-acm-tutorial/ingress-gateway/init
    auth: none

Étant donné que les rapprocheurs RepoSync ont besoin d'autorisations supplémentaires pour créer des ressources Istio, un objet ClusterRole et deux objets RoleBinding permettant d'accorder ces autorisations sont également appliqués à votre cluster :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: custom:aggregate-to-edit:istio
rules:
- apiGroups:
  - "networking.istio.io"
  - "security.istio.io"
  resources:
  - "virtualservices"
  - "authorizationpolicies"
  - "gateways"
  verbs:
  - "*"

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: repo-sync
subjects:
- kind: ServiceAccount
  name: ns-reconciler-onlineboutique
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: repo-sync
subjects:
- kind: ServiceAccount
  name: ns-reconciler-asm-ingress
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Pour vous assurer que Policy Controller et Config Sync ont bien été installés, vérifiez leur état :
```
gcloud beta container fleet config-management status
```
Le résultat ressemble à ce qui suit :
```
Name: asm-acm-tutorial
Status: SYNCED
Last_Synced_Token: 4b3384d
Sync_Branch: main
Last_Synced_Time: 2022-05-04T21:32:58Z
Policy_Controller: INSTALLED
Hierarchy_Controller: PENDING
```
Si PENDING ou NOT_INSTALLED s'affichent dans les lignes Status ou Policy_Controller, attendez quelques minutes et exécutez à nouveau gcloud beta container fleet config-management status.

Pour garantir l'installation réussie de Cloud Service Mesh, décrivez son état :

gcloud container fleet mesh describe

Le résultat ressemble à ce qui suit :

createTime: '2022-09-13T23:12:56.477042921Z'
membershipSpecs:
  projects/PROJECT_NUMBER/locations/global/memberships/asm-acm-tutorial:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/asm-acm-tutorial:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision(s) ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
      updateTime: '2022-09-14T00:19:10.571552206Z'
name: projects/PROJECT_ID/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
state:
  state: {}
updateTime: '2022-09-14T00:19:14.135113118Z'

Si state.code: ERROR s'affiche au lieu de state.code: OK, attendez quelques minutes et exécutez à nouveau gcloud container fleet mesh describe. Avant de poursuivre le tutoriel, vous devez vous assurer que le champ servicemesh.controlPlaneManagement.details.code contient la valeur REVISION_READY.

Déployer une passerelle d'entrée et un exemple d'application

Dans cette section, vous allez déployer Exemple d'application Boutique en ligne et une passerelle d'entrée pour gérer le trafic entrant.

Déployez l'exemple d'application Boutique en ligne et la passerelle d'entrée.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources dont vous avez besoin pour déployer la passerelle d'entrée et l'exemple d'application.
```
sed -i "s,root-sync/init,root-sync/deployments,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml
```
Cette étape peut prendre quelques minutes.

Affichez l'état de Config Sync pour RootSync et les deux RepoSyncs :

gcloud alpha anthos config sync repo describe

Le résultat est semblable à :

getting 3 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/deployments@main",
    "status": "SYNCED"
  },
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/ingress-gateway/deployments@main",
    "status": "SYNCED"
  },
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/online-boutique/deployments@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Pour afficher uniquement les informations d'un dépôt, vous pouvez utiliser les options --sync-name et --sync-namespace. Pour afficher les ressources gérées en détail, ajoutez l'option --managed-resources. Pour en savoir plus, consultez la page Afficher l'état de Config Sync sur plusieurs clusters.

Attendez que l'adresse IP publique de la passerelle d'entrée soit provisionnée :

until kubectl -n asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"; do : ; done

Récupérez l'adresse IP publique de la passerelle d'entrée :

EXTERNAL_IP=$(kubectl get svc asm-ingressgateway -n asm-ingress -o jsonpath="{.status.loadBalancer.ingress[*].ip}")

Accédez à l'adresse IP depuis votre navigateur pour vérifier que l'application Boutique en ligne a bien été déployée :
```
echo http://${EXTERNAL_IP}
```

Appliquer des règles pour sécuriser le maillage

Dans les sections suivantes, vous allez utiliser Policy Controller pour appliquer les règles du groupe de règles Cloud Service Mesh en créant des contraintes.

Appliquer l'injection de proxys side-car

Dans cette section, vous appliquez des règles pour vous assurer que l'injection side-car automatique est activée sur toutes les charges de travail du maillage.

Pour appliquer l'injection de proxys side-car, appliquez des contraintes.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.

sed -i "s,root-sync/deployments,root-sync/enforce-sidecar-injection,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

La commande précédente déploie les ressources suivantes :

Un Constraint K8sRequiredLabels nécessitant qu'un élément Namespace du maillage contienne le libellé d'injection de proxy side-car Cloud Service Mesh spécifique :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: namespace-sidecar-injection-label
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Namespace
    excludedNamespaces:
    - config-management-monitoring
    - config-management-system
    - default
    - gatekeeper-system
    - gke-connect
    - istio-system
    - kube-node-lease
    - kube-public
    - kube-system
    - resource-group-system
  parameters:
    labels:
    - allowedRegex: enabled
      key: istio-injection

Une contrainte (Constraint) AsmSidecarInjection qui interdit à un Pod du maillage de contourner l'injection de proxy side-car Istio :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmSidecarInjection
metadata:
  name: pod-sidecar-injection-annotation
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod
    excludedNamespaces:
    - kube-system
  parameters:
    strictnessLevel: High

Affichez l'état de Config Sync pour RootSync :

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

Le résultat est semblable à :

getting 1 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-sidecar-injection@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Vérifiez que les contraintes (Constraints) sont créées :

kubectl get constraints

Policy Controller peut prendre quelques minutes pour évaluer ces contraintes. Si aucune valeur ne s'affiche dans la colonne TOTAL-VIOLATIONS, attendez et exécutez à nouveau kubectl get constraints.

Le résultat est semblable à :

NAME                                                                                       ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
podsidecarinjectionannotation.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0

NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0

Comme nous avons correctement configuré Namespaces et Pods, il existe 0 TOTAL-VIOLATIONS pour ces Constraints.

Pour voir ces Constraints en action, essayez de créer un Namespace dans votre cluster sans label ni annotation :

kubectl create namespace test

La sortie ressemble à ce qui suit :

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [namespace-sidecar-injection-label] you must provide labels: {"istio-injection"}

Appliquer le chiffrement du trafic

Dans cette section, vous appliquez des règles pour vous assurer que tout le trafic du maillage est chiffré.

Pour appliquer le chiffrement du trafic, appliquez des contraintes.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.

sed -i "s,root-sync/enforce-sidecar-injection,root-sync/enforce-strict-mtls,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

La commande précédente déploie les ressources suivantes :

Un Constraint AsmPeerAuthnMeshStrictMtls qui applique l'authentification mTLS PeerAuthentication au niveau du maillage dans l'espace de noms istio-system :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmPeerAuthnMeshStrictMtls
metadata:
  name: mesh-level-strict-mtls
spec:
  enforcementAction: deny
  parameters:
    rootNamespace: istio-system
    strictnessLevel: High

Une contrainte référentielle Config dans l'espace de noms gatekeeper-system. Cette contrainte référentielle permet à la contrainte (Constraint) AsmPeerAuthnMeshStrictMtls de référencer un autre objet dans sa définition (par exemple, la recherche de PeerAuthentication dans l'espace de noms (Namespace) istio-system) :

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "security.istio.io"
        version: "v1beta1"
        kind: "PeerAuthentication"
      - group: "security.istio.io"
        version: "v1beta1"
        kind: "AuthorizationPolicy"

Une contrainte (Constraint) DestinationRuleTLSEnabled qui interdit la désactivation du protocole TLS pour tous les hôtes et sous-ensembles d'hôtes dans les DestinationRules d'Istio :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DestinationRuleTLSEnabled
metadata:
  name: destination-rule-tls-enabled
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - networking.istio.io
      kinds:
      - DestinationRule

Une contrainte (Constraint) AsmPeerAuthnStrictMtls qui exige que toutes les PeerAuthentications ne puissent pas écraser le protocole mTLS en mode STRICT :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmPeerAuthnStrictMtls
metadata:
  name: peerauthentication-strict-mtls
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - security.istio.io
      kinds:
      - PeerAuthentication
  parameters:
    strictnessLevel: High

Affichez l'état de Config Sync pour RootSync :

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

Le résultat est semblable à :

getting 1 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-strict-mtls@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Exécutez la commande suivante pour obtenir plus d'informations sur le cas de non-respect PeerAuthentication :

kubectl get asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls -ojsonpath='{.status.violations}'  | jq

Le résultat est semblable à :

[
  {
    "enforcementAction": "deny",
    "group": "constraints.gatekeeper.sh",
    "kind": "AsmPeerAuthnMeshStrictMtls",
    "message": "Root namespace <istio-system> does not have a strict mTLS PeerAuthentication",
    "name": "mesh-level-strict-mtls",
    "version": "v1beta1"
  }
]

Corrigez le problème en déployant une PeerAuthentication dans istio-system. Pour empêcher tous vos services du maillage d'accepter le trafic en texte brut, définissez une règle PeerAuthentication à l'échelle du maillage avec le mode mTLS défini sur STRICT. Lorsque vous déployez la règle, le plan de contrôle provisionne automatiquement les certificats TLS afin que les charges de travail puissent s'authentifier mutuellement.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.
```
sed -i "s,root-sync/enforce-strict-mtls,root-sync/fix-strict-mtls,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml
```
La commande ci-dessus déploie l'authentification PeerAuthentication du protocole mTLS en mode STRICT suivante dans l'espace de noms istio-system. Elle applique l'authentification mTLS en mode STRICT à l'ensemble du maillage :
```
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
```

Affichez l'état de Config Sync pour RootSync :

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

Le résultat est semblable à :

getting 1 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/fix-strict-mtls@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Vérifiez que les contraintes (Constraints) sont créées :

kubectl get constraints

Notez que Policy Controller peut prendre quelques minutes pour évaluer ces Constraints. Attendez et exécutez à nouveau cette commande kubectl get constraints jusqu'à obtenir des valeurs sous la colonne TOTAL-VIOLATIONS pour chaque ligne.

Le résultat est semblable à :

NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0
NAME                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls   deny                 0
NAME                                                                               ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
destinationruletlsenabled.constraints.gatekeeper.sh/destination-rule-tls-enabled   deny                 0
NAME                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnstrictmtls.constraints.gatekeeper.sh/peerauthentication-strict-mtls   deny                 0
NAME                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmsidecarinjection.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0

Appliquer un contrôle d'accès précis

Dans cette section, vous appliquez des règles pour vous assurer que toutes les charges de travail du maillage disposent d'un contrôle d'accès précis.

Pour appliquer un contrôle d'accès précis, appliquez des contraintes.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.

sed -i "s,root-sync/fix-strict-mtls,root-sync/enforce-authorization-policies,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

La commande précédente déploie les ressources suivantes :

Une Constraint AsmAuthzPolicyDefaultDeny qui applique l'AuthorizationPolicy de refus par défaut au niveau du maillage dans l'espace de noms istio-system :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmAuthzPolicyDefaultDeny
metadata:
  name: default-deny-authorization-policies
spec:
  enforcementAction: deny
  parameters:
    rootNamespace: istio-system
    strictnessLevel: High

Une contrainte (Constraint) AsmAuthzPolicyEnforceSourcePrincipals qui exige que toute AuthorizationPolicies définisse des comptes principaux sources précis (autres que "*"). Seule la passerelle d'entrée de l'espace de noms asm-ingress fait exception à cette règle afin de recevoir le trafic des utilisateurs finaux et le rediriger vers l'application frontend de boutique en ligne.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmAuthzPolicyEnforceSourcePrincipals
metadata:
  name: authz-source-principals-not-all
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - security.istio.io
      kinds:
      - AuthorizationPolicy
    excludedNamespaces:
      - asm-ingress

Affichez l'état de Config Sync pour RootSync :

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

Le résultat est semblable à :

getting 1 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-authorization-policies@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Exécutez la commande suivante pour obtenir plus d'informations sur le cas de non-respect associé :

kubectl get asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/default-deny-authorization-policies -ojsonpath='{.status.violations}'  | jq

Le résultat est semblable à :

[
  {
    "enforcementAction": "deny",
    "group": "constraints.gatekeeper.sh",
    "kind": "AsmAuthzPolicyDefaultDeny",
    "message": "Root namespace <istio-system> does not have a default deny AuthorizationPolicy",
    "name": "default-deny-authorization-policies",
    "version": "v1beta1"
  }
]

Corrigez le problème en déployant AuthorizationPolicy dans l'espace de noms istio-system.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.

sed -i "s,root-sync/enforce-authorization-policies,root-sync/fix-default-deny-authorization-policy,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

La commande ci-dessus déploie la règle d'autorisation (AuthorizationPolicy) de refus suivante dans l'espace de noms istio-system :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  {}

Affichez l'état de Config Sync pour RootSync :

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

Le résultat est semblable à :

getting 1 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/fix-default-deny-authorization-policy@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Vérifiez que les contraintes (Constraints) sont créées :

kubectl get constraints

Le résultat est semblable à :

NAME                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmsidecarinjection.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0
NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0
NAME                                                                                      ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/default-deny-authorization-policies   deny                 0
NAME                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls   deny                 0
NAME                                                                               ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
destinationruletlsenabled.constraints.gatekeeper.sh/destination-rule-tls-enabled   deny                 0
NAME                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnstrictmtls.constraints.gatekeeper.sh/peerauthentication-strict-mtls   deny                 0
NAME                                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmauthzpolicyenforcesourceprincipals.constraints.gatekeeper.sh/authz-source-principals-not-all   deny                 0

Accédez à l'application Boutique en ligne depuis votre navigateur :
```
echo http://${EXTERNAL_IP}
```
Vous devriez recevoir l'erreur RBAC: access denied, qui confirme que la règle d'autorisation (AuthorizationPolicy) de refus par défaut s'applique à l'ensemble du maillage.

Corrigez ce problème en déployant des éléments AuthorizationPolicies plus précis dans les espaces de noms asm-ingress et onlineboutique.

La commande suivante utilise sed pour mettre à jour le fichier manifeste acm-config.yaml afin que Config Sync déploie les ressources associées.

sed -i "s,root-sync/fix-default-deny-authorization-policy,root-sync/deploy-authorization-policies,g" ~/asm-acm-tutorial-dir/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${MEMBERSHIP} \
    --config ~/asm-acm-tutorial-dir/acm-config.yaml

La commande précédente déploie les ressources suivantes :

Un AuthorizationPolicy dans l'espace de noms asm-ingress :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: asm-ingressgateway
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  rules:
  - to:
    - operation:
        ports:
        - "8080"

Une AuthorizationPolicy par application dans l'espace de noms onlineboutique. Voici l'exemple pour l'application cartservice :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: cartservice
spec:
  selector:
    matchLabels:
      app: cartservice
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/onlineboutique/sa/frontend
        - cluster.local/ns/onlineboutique/sa/checkoutservice
    to:
    - operation:
        paths:
        - /hipstershop.CartService/AddItem
        - /hipstershop.CartService/GetCart
        - /hipstershop.CartService/EmptyCart
        methods:
        - POST
        ports:
        - "7070"

Un ServiceAccount par application dans les espaces de noms asm-ingress et onlineboutique, afin de disposer d'une identité unique par application évaluée comme principal dans les AuthorizationPolicies. Voici l'exemple pour l'application cartservice :
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cartservice
```

Affichez l'état de Config Sync pour RootSync et les deux RepoSyncs :

gcloud alpha anthos config sync repo describe

Le résultat est semblable à :

getting 3 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/deploy-authorization-policies@main",
    "status": "SYNCED"
  },
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/ingress-gateway/authorization-policies@main",
    "status": "SYNCED"
  },
  {
    "clusters": [
      "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/online-boutique/authorization-policies@main",
    "status": "SYNCED"
  }
]

Si status: RECONCILING s'affiche au lieu de status: SYNCED, attendez quelques minutes et exécutez à nouveau gcloud alpha anthos config sync repo describe.

Pour afficher uniquement les informations d'un dépôt, vous pouvez utiliser les options --sync-name et --sync-namespace. Vous pouvez également ajouter l'option --managed-resources pour afficher les ressources gérées en détail. Pour en savoir plus, consultez la page Afficher l'état de Config Sync sur plusieurs clusters.

Accédez de nouveau à l'application Boutique en ligne depuis votre navigateur :
```
echo http://${EXTERNAL_IP}
```
Si vous attendez quelques minutes, vous devriez constater que le site Web fonctionne à nouveau comme prévu.

Afficher l'état des fonctionnalités de sécurité de GKE Enterprise

Vous pouvez consulter l'état des fonctionnalités de sécurité de GKE Enterprise, y compris les règles d'authentification et d'autorisation, dans la console Google Cloud.

Dans la console Google Cloud, accédez à la page Sécurité de GKE Enterprise.

Accéder à la sécurité de GKE Enterprise

Le récapitulatif des règles affiche l'état de la sécurité des applications, y compris le contrôle des accès aux services (AuthorizationPolicies) et l'authentification mTLS.
Cliquez sur Audit des règles pour afficher l'état de conformité avec les règles de la charge de travail pour le cluster et les deux espaces de noms (asm-ingress et onlineboutique).

Les fiches Contrôle des accès aux services et État mTLS fournissent une vue d'ensemble.

La liste Charges de travail affiche le contrôle d'accès aux services et l'état mTLS de chaque charge de travail.

Vous avez désormais sécurisé votre cluster et votre maillage à l'aide de Policy Controller et de Config Sync.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Supprimer des ressources individuelles

Pour supprimer les ressources individuelles, procédez comme suit :

Annulez l'enregistrement de votre cluster dans le parc :

gcloud

gcloud container fleet memberships unregister ${CLUSTER} \
    --project=${PROJECT_ID} \
    --gke-cluster=${CLUSTER_ZONE}/${CLUSTER}

Le résultat ressemble à ce qui suit :

kubeconfig entry generated for asm-acm-tutorial.
Waiting for membership to be deleted...done.
Deleting membership CR in the cluster...done.
Deleting namespace [gke-connect] in the cluster...done.

Config Connector

kubectl delete -f ~/asm-acm-tutorial-dir/fleet-membership.yaml

Supprimez votre cluster :

gcloud

gcloud container clusters delete ${CLUSTER} \
    --zone ${CLUSTER_ZONE}

Appuyez sur y lorsque vous y êtes invité. L'exécution de cette commande peut prendre plus de cinq minutes.

Le résultat ressemble à ce qui suit :

Deleting cluster asm-acm-tutorial...done.
Deleted [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/us-east4-a/clusters/asm-acm-tutorial].

Config Connector

kubectl delete -f ~/asm-acm-tutorial-dir/container-cluster.yaml

Supprimez les fichiers que vous avez créés :
```
rm -r ~/asm-acm-tutorial-dir
```

Étape suivante

Découvrez les bonnes pratiques de sécurité pour Cloud Service Mesh.
En savoir plus sur le groupe de règles Cloud Service Mesh
Explorez la bibliothèque de modèles de contraintes Policy Controller.
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.