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 de sa boutique en ligne à l'aide de Cloud Service Mesh, une 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 éviter les erreurs de configuration et valider automatiquement vos règles Cloud Service Mesh à l'aide de Policy Controller et de 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 groupe 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

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 :

  2. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  3. Passez à la dernière version de Google Cloud CLI :

    gcloud components update

  4. Pour stocker les fichiers que vous créez dans ce tutoriel, créez un répertoire :

    mkdir ~/asm-acm-tutorial-dir

  5. 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.

  6. 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.

    7. Configurer un cluster GKE

    Dans cette section, vous allez créer un cluster GKE, puis l'enregistrer dans un parc. Un parc est un conceptGoogle 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 le cluster sur lequel vous installez Cloud Service Mesh, Policy Controller et Config Sync. 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 :

    1. 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}. \
    --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.

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

      Cette opération peut prendre plus de cinq minutes.

    2. 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

    3. Connectez-vous au cluster GKE :

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

    4. 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

    5. Pour garantir l'enregistrement réussi du cluster GKE, 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 appliquez un 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 :

    1. Activez 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

    2. 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

    3. 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

    4. Activez Config Sync et Policy Controller :

      gcloud

      Enregistrez le 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 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

    5. Pour garantir l'installation réussie de Policy Controller et de Config Sync, vérifiez l'é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

      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.

    6. 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 l'exemple d'application Boutique en ligne et une passerelle d'entrée pour gérer le trafic entrant.

    1. 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.

    2. 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.

    3. 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

    4. 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}")

    5. 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.

    1. 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 K8sRequiredLabels Constraint 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

    2. 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.

    3. 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.

    4. 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é.

    1. 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

    2. 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.

    3. 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"
  }
]

    4. 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

    5. 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.

    6. 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.

    1. 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

    2. 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.

    3. 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"
  }
]

    4. 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:
  {}

    5. 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.

    6. 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
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

    7. 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.

    8. 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

    9. 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.

    10. 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é GKE Enterprise

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

    1. Dans la console Google Cloud , accédez à la page Sécurité 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.

    2. 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.

      Vue d&#39;ensemble du contrôle d&#39;accès aux services et de l&#39;état mTLS

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

      Liste détaillée de chaque charge de travail, de son contrôle des accès aux services et de l&#39;état mTLS

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