Guide de démarrage rapide : Surveiller la sécurité des pods avec la validation continue

Découvrez comment faire vos premiers pas avec la validation continue de l'autorisation binaire avec des règles basées sur la vérification. Dans ce guide de démarrage rapide, vous allez utiliser les vérifications CV suivantes pour valider en continu les pods en cours d'exécution pour les conditions suivantes :

  • Répertoire de confiance: vérifie que les images associées au pod se trouvent dans un ou plusieurs répertoires de confiance que vous spécifiez dans la règle.
  • Fraîcheur d'image : vérifie que les images du pod ont été importées au maximum depuis un nombre de jours spécifié dans la règle.

Avant de commencer

  1. Connectez-vous à votre Google Cloud compte. Si vous n'avez jamais utilisé Google Cloud, créez un compte pour évaluer les performances de nos produits dans des scénarios réels. Les nouveaux clients bénéficient également de 300 $de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  2. Installez Google Cloud CLI.

  3. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  4. Pour initialiser gcloud CLI, exécutez la commande suivante : 

    gcloud init

  5. Sélectionnez ou créez un Google Cloud projet.

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionner un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

    • Créez un Google Cloud projet :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du Google Cloud projet que vous créez.

    • Sélectionnez le Google Cloud projet que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre Google Cloud projet.

  6. Vérifiez que la facturation est activée pour votre Google Cloud projet.

  7. Activez les API Autorisation binaire et Google Kubernetes Engine :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin), qui contient l' serviceusage.services.enable autorisation. Découvrez comment attribuer des rôles. 

    gcloud services enable container.googleapis.com binaryauthorization.googleapis.com

  8. Installez Google Cloud CLI.

  9. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  10. Pour initialiser gcloud CLI, exécutez la commande suivante : 

    gcloud init

  11. Sélectionnez ou créez un Google Cloud projet.

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionner un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

    • Créez un Google Cloud projet :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du Google Cloud projet que vous créez.

    • Sélectionnez le Google Cloud projet que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre Google Cloud projet.

  12. Vérifiez que la facturation est activée pour votre Google Cloud projet.

  13. Activez les API Autorisation binaire et Google Kubernetes Engine :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin), qui contient l' serviceusage.services.enable autorisation. Découvrez comment attribuer des rôles. 

    gcloud services enable container.googleapis.com binaryauthorization.googleapis.com
    14.
  14. Installez l'outil de ligne de commande kubectl.
  15. Si vos stratégies d'autorisation binaire et vos clusters GKE se trouvent dans des projets différents, assurez-vous que l'autorisation binaire est activée dans les deux projets.

Créer une règle de plate-forme

Pour configurer une règle de plate-forme GKE pour la CV, procédez comme suit :

  1. Créez le fichier YAML de règle de plate-forme :

    cat << EOF > /tmp/my-policy.yaml
gkePolicy:
  checkSets:
  - checks:
    - trustedDirectoryCheck:
        trustedDirPatterns:
        - us-central1-docker.pkg.dev/my-project/my-directory
      displayName: My trusted directory check
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: My image freshness check
    displayName: My trusted directory and image freshness check set
EOF

    Cette règle vérifie les conditions suivantes :

    • Les images des pods sont stockées dans le dépôt Artifact Registry nommé us-central1-docker.pkg.dev/my-project/my-directory.

    • Les images des pods ont été importées dans les dépôts Artifact Registry ou Container Registry au cours des 30 derniers jours.

  2. Créez la règle de plate-forme :

    gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=/tmp/my-policy.yaml \
    --project=POLICY_PROJECT_ID

    Remplacez les éléments suivants :

    • POLICY_ID : ID de votre choix
    • POLICY_PROJECT_ID : ID du projet de règles

Créer ou mettre à jour un cluster

Pour activer la CV sur un cluster, vous pouvez créer un cluster ou mettre à jour un cluster existant.

  • Pour créer un cluster avec la règle de plate-forme basée sur les vérifications activée, exécutez la commande suivante :

    gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : emplacement (par exemple : us-central1 ou asia-south1)
    • POLICY_PROJECT_ID : ID du projet dans lequel la règle est stockée
    • POLICY_ID : ID de la règle
    • CLUSTER_PROJECT_ID : ID de projet du cluster

    Attendez que le cluster soit créé.

  • Pour mettre à jour un cluster existant avec les règles basées sur des vérifications activées, exécutez la commande suivante.

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : emplacement (par exemple : us-central1 ou asia-south1)
    • POLICY_PROJECT_ID : ID du projet dans lequel la règle est stockée
    • POLICY_ID : ID de la règle
    • CLUSTER_PROJECT_ID : ID de projet du cluster

    Attendez que le cluster soit mis à jour.

Déployer une image

  1. Obtenez l'identifiant pour kubectl :

    gcloud container clusters get-credentials CLUSTER_NAME

  2. Déployez une image :

    kubectl run hello-app \
    --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

    L'image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 répond à la vérification d'actualisation, car elle a été importée dans le dépôt au cours des 30 derniers jours. Mais l'image échoue à la vérification du répertoire de confiance, car elle ne se trouve pas dans us-central1-docker.pkg.dev/my-project/my-directory. Par conséquent, la CV génère des entrées de journal TrustedDirectoryCheck dans Cloud Logging.

Afficher les journaux

L'entrée de journal apparaît dans Cloud Logging dans les 24 heures suivant le déploiement du pod, mais elle peut apparaître en quelques heures seulement.

Pour afficher le journal dans Cloud Logging, utilisez le filtre suivant :

logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation"
"policyName"

Le journal du pod hello-app est semblable à celui ci-dessous. Certains champs peuvent être différents selon l'ID de votre projet, le nom du cluster, etc…

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/1234567890/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "Default check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

L'entrée de journal affiche des informations sur le cas de non-respect des règles, y compris les champs suivants :

  • policyName : règle de plate-forme utilisée par la CV lors de l'identification de la violation

  • checkResults : bloc de résultats qui inclut les champs suivants :

    • explanation : message d'erreur
    • checkSetName : valeur displayName de l'ensemble de vérifications
    • checkSetIndex : index de l'ensemble de vérifications dans la règle
    • checkName : nom de la vérification
    • checkIndex : index de la vérification dans l'ensemble de test
    • verdict : verdict ayant entraîné la création de l'entrée de journal (dans le cas présent, NOT_CONFORMANT), car la vérification a n'a pas été satisfaite.

Certaines vérifications peuvent inclure des informations supplémentaires afin de vous aider à comprendre pourquoi la vérification n'a pas été satisfaite.

Comme l'image satisfait la vérification de fraîcheur, elle n'apparaît pas dans le journal.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans cette démonstration soient facturées sur votre Google Cloud compte pour les ressources utilisées sur cette page, supprimez le Google Cloud projet qui les contient.

Cette section explique comment nettoyer la surveillance CV que vous avez configurée précédemment dans ce guide.

Vous pouvez désactiver la surveillance CV ou l'autorisation binaire et la CV dans votre cluster.

Désactiver l'autorisation binaire dans un cluster

Pour désactiver la CV et l'application forcée de l'autorisation binaire dans votre cluster, exécutez la commande suivante :

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement du cluster
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Désactiver la surveillance des règles basées sur des vérifications dans un cluster

Pour désactiver la CV avec des règles basées sur la vérification dans le cluster et réactiver l'application forcée à l'aide de la règle d'application de l'autorisation binaire, exécutez la commande suivante :

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement du cluster
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Notez que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE équivaut à l'ancienne option --enable-binauthz.

Supprimer la stratégie

Pour supprimer la règle, exécutez la commande suivante. Il n'est pas nécessaire de supprimer la règle de plate-forme basée sur des vérifications pour désactiver son audit.

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

Remplacez les éléments suivants :

  • POLICY_ID : ID de la règle
  • POLICY_PROJECT_ID : ID du projet de règles

Étapes suivantes