Vérifier les connexions Google au plan de contrôle GKE

Cette page explique comment vérifier les connexions établies par le personnel de Google avec le plan de contrôle de votre cluster Google Kubernetes Engine (GKE) en corrélant les journaux GKE avec les journaux Access Transparency.

Les journaux Access Transparency enregistrent les actions effectuées par le personnel de Google lorsqu'il accède à votre contenu. Ce guide est destiné aux administrateurs de la sécurité qui souhaitent une vérification supplémentaire du contenu des journaux Access Transparency et des approbations Access Approval associées en les corrélant avec des sources de journalisation supplémentaires de GKE. Cette vérification est entièrement facultative et n'est pas requise pour sécuriser votre plan de contrôle.

Assurez-vous de connaître les concepts suivants :

Cette page décrit une partie d'un ensemble de fonctionnalités facultatives du plan de contrôle dans GKE qui vous permettent d'effectuer des tâches telles que la vérification de votre niveau de sécurité du plan de contrôle ou la configuration du chiffrement et de la signature des identifiants dans le plan de contrôle à l'aide de clés que vous gérez. Pour en savoir plus, consultez À propos de GKE control plane authority.

Par défaut, Cloud de Confiance applique diverses mesures de sécurité au plan de contrôle géré. Cette page décrit les fonctionnalités facultatives qui vous offrent plus de visibilité ou de contrôle sur le plan de contrôle GKE.

À propos de l'accès de Google aux instances du plan de contrôle du cluster

Lors des sessions de dépannage ou pour d'autres raisons commerciales justifiées, le personnel de Google, comme les ingénieurs en fiabilité des sites et les employés de l'Cloud Customer Care, peut avoir besoin d'un accès administrateur aux instances Compute Engine qui hébergent votre plan de contrôle. En fonction de votre forfait d'assistance client et de votre configuration, Access Transparency fournit une journalisation d'audit détaillée pour cet accès administrateur. Access Approval vous permet d'exiger une approbation explicite avant que le personnel de Google puisse accéder à vos ressources. Pour en savoir plus sur l'accès administrateur et les outils que vous pouvez utiliser pour autoriser l'accès et enregistrer les modifications, consultez Accès administrateur pour les employés Google.

Journaux d'accès au plan de contrôle

Lorsque vous activez GKE control plane authority, GKE génère des journaux d'accès au plan de contrôle que vous pouvez éventuellement utiliser pour croiser les journaux d'audit générés par Access Transparency et Access Approval. GKE adds control plane access logs to the _Default bucket in Logging to record incoming network connections and specific SSH events in your control plane instances. Vous devez activer GKE control plane authority dans votre projet pour générer des journaux d'accès au plan de contrôle pour vos clusters.

GKE génère les journaux d'accès suivants pour le plan de contrôle :

Le volume des journaux de connexion au plan de contrôle dépend de facteurs tels que le nombre de nœuds dans le cluster, le nombre d'instances du plan de contrôle (les clusters régionaux en comportent plus que les clusters zonaux) et la fréquence à laquelle vos charges de travail appellent le serveur d'API Kubernetes. Le volume des journaux SSH est faible et dépend du nombre de redémarrages de nœuds.

Pour vérifier les connexions à votre plan de contrôle, recherchez les journaux d'accès au plan de contrôle de votre cluster et faites-les correspondre aux journaux d'audit d'Access Transparency et d'Access Approval. Vous pouvez ainsi confirmer que toutes les connexions SSH à vos instances de plan de contrôle ont été établies suite à un accès administrateur autorisé par le personnel de Google. Lorsque vous activez GKE control plane authority pour votre cluster, tout accès SSH du personnel de Google à votre plan de contrôle est non interactif, ce qui signifie que chaque connexion SSH exécute une seule commande que vous autorisez. Pour afficher les détails au niveau des commandes pour l'accès administrateur, inscrivez-vous à Augmented Access Approval et Augmented Access Transparency. Pour en savoir plus sur l'éligibilité et l'inscription, contactez votre Cloud de Confiance by S3NS équipe chargée du compte.

Tarifs

Les considérations tarifaires suivantes s'appliquent :

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Activez l'API Cloud Logging.

    Rôles requis pour activer les API

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

    Activer l'API

  • Activez Access Transparency pour votre organisation. Pour savoir comment procéder, consultez Activer Access Transparency.

  • Vous pouvez également activer Access Approval pour votre projet et sélectionner le service GKE. Pour savoir comment procéder, consultez Examiner et approuver les demandes d'accès à l'aide de la clé de signature gérée par Google.

  • Assurez-vous que votre environnement est éligible à l'utilisation des fonctionnalités de GKE control plane authority. Pour activer ces fonctionnalités, contactez votre Cloud de Confiance équipe commerciale.

Conditions requises

Les journaux d'accès au plan de contrôle nécessitent GKE version 1.31.1-gke.1846000 ou ultérieure.

Rôles et autorisations requis

Pour obtenir les autorisations nécessaires pour activer la génération de journaux, ainsi que pour accéder aux journaux et les traiter, demandez à votre administrateur de vous attribuer les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Activer les journaux d'accès au plan de contrôle du cluster GKE

Vous pouvez activer la génération de journaux d'accès au plan de contrôle pour les clusters en mode Autopilot et en mode Standard en activant le composant de journalisation correspondant. Pour en savoir plus sur les types de journaux du plan de contrôle, consultez Afficher les journaux GKE.

Les noms de composants de journalisation compatibles pour les journaux d'accès au plan de contrôle sont les suivants :

  • Journaux SSH du plan de contrôle : KCP_SSHD
  • Journaux de connexion au plan de contrôle : KCP_CONNECTION

Activer les journaux d'accès au plan de contrôle sur un nouveau cluster

L'exemple suivant crée un cluster en mode Autopilot avec les deux types de journaux d'accès au plan de contrôle activés. Pour n'activer qu'un seul type de journal d'accès au plan de contrôle, omettez le nom du composant correspondant dans la commande.

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,KCP_SSHD,KCP_CONNECTION

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du nouveau cluster.
  • LOCATION : emplacement où créer le cluster.

Pour spécifier des composants de journalisation lorsque vous créez un cluster à l'aide de l' API GKE, dans la projects.locations.clusters.create méthode, définissez les valeurs correspondantes dans l' LoggingConfig objet de la Cluster ressource.

Activer les journaux d'accès au plan de contrôle sur un cluster existant

Pour mettre à jour la configuration de journalisation d'un cluster existant afin d'activer les journaux d'accès au plan de contrôle, procédez comme suit :

  1. Recherchez les composants de journalisation existants utilisés par votre cluster.
  2. Identifiez les valeurs correspondantes à spécifier dans l'option --logging de la gcloud CLI pour que ces composants de journalisation restent activés.
  3. Mettez à jour la configuration de journalisation de votre cluster pour activer les journaux d'accès au plan de contrôle en plus de votre configuration de journalisation existante.

Les valeurs que vous spécifiez pour l'option --logging dans la commande gcloud container clusters update sont différentes de celles que vous voyez lorsque vous décrivez votre cluster.

  1. Vérifiez la configuration de journalisation existante du cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    Le résultat ressemble à ce qui suit :

    SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

  2. Identifiez les valeurs de la gcloud CLI pour l'option --logging qui correspondent à la configuration du composant de journalisation à partir du résultat de l'étape précédente. Pour obtenir la liste des valeurs de la gcloud CLI qui correspondent à des composants de journalisation spécifiques, consultez le tableau Journaux disponibles.

  3. Mettez à jour la configuration de journalisation avec les journaux d'accès au plan de contrôle :

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,EXISTING_LOGS,KCP_ACCESS_LOGS

    Remplacez les éléments suivants :

    • EXISTING_LOGS: liste de composants de journalisation séparés par une virgule que votre cluster utilise déjà. Assurez-vous de spécifier les valeurs de la gcloud CLI qui correspondent à ces composants de journalisation, extraites du tableau Journaux disponibles.

    • KCP_ACCESS_LOGS: liste des types de journaux d'accès au plan de contrôle à activer pour le cluster, séparés par une virgule, comme suit :

      • Pour les journaux SSH du plan de contrôle, spécifiez KCP_SSHD.
      • Pour les journaux de connexion au plan de contrôle, spécifiez KCP_CONNECTION.

Pour spécifier des composants de journalisation lorsque vous mettez à jour un cluster à l'aide de l' API GKE, dans la projects.locations.clusters.update méthode, définissez les valeurs des composants de journalisation existants et nouveaux dans l' LoggingConfig objet de la ClusterUpdate ressource.

Exemple de mise à jour de cluster pour activer les journaux d'accès au plan de contrôle

Prenons l'exemple d'un cluster qui affiche la configuration de journalisation suivante après l'exécution de la commande gcloud container clusters describe :

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

La commande de mise à jour de cluster suivante active les deux types de journaux d'accès au plan de contrôle tout en conservant la configuration de journalisation existante pour cet exemple de cluster :

gcloud container clusters update example-cluster \
    --location=us-central1 \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

Croiser les journaux d'accès au plan de contrôle avec les journaux Access Transparency

Pour vérifier l'accès au plan de contrôle d'un cluster, obtenez les journaux de connexion au plan de contrôle, les journaux SSH du plan de contrôle et les journaux Access Transparency pour ce cluster :

  1. Dans la Cloud de Confiance console, ouvrez la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Pour obtenir tous les journaux d'un cluster spécifique, y compris les journaux d'accès au plan de contrôle et les journaux Access Transparency, exécutez la requête suivante :

    (logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection"
resource.labels.cluster_name="CLUSTER_NAME"
jsonPayload.connection.dest_port="22")
OR
(logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-sshd"
resource.labels.cluster_name="CLUSTER_NAME")
OR
(logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
json_payload.accesses.methodName="GoogleInternal.SSH.Master"
json_payload.accesses.resourceName="//container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME")

Le résultat doit afficher tous les types de journaux suivants pour votre cluster :

  • Journal Access Transparency
  • Journal de connexion au plan de contrôle
  • Journaux SSH pour chaque session SSH

Effectuer des vérifications

Votre principale vérification consiste à déterminer si vous voyez tous les types de journaux pour les connexions SSH lorsque vous exécutez la requête Logging à partir de la section précédente. Chaque journal Access Transparency doit avoir un journal de connexion au plan de contrôle correspondant et un ou plusieurs journaux SSH. Ces journaux concernent les actions effectuées par des personnes dans vos instances de plan de contrôle. Le volume de journaux doit donc être faible.

Vous pouvez également effectuer les vérifications supplémentaires suivantes du contenu des journaux :

  1. Pour chaque journal SSH du plan de contrôle, vérifiez si un journal Access Transparency existe dans une fenêtre de 15 minutes avant l'horodatage du journal SSH. Cette fenêtre temporelle tient compte de la fermeture finale de la session SSH qui se produit plusieurs minutes après l'enregistrement de la connexion initiale par Access Transparency.
  2. Pour chaque journal de connexion au plan de contrôle, vérifiez si un journal Access Transparency existe dans une fenêtre de 5 minutes avant l'horodatage du journal de connexion au plan de contrôle.

  3. Si vous utilisez Access Approval pour votre cluster, vérifiez si chaque journal Access Transparency comporte un champ accessApprovals correspondant. Croisez ce champ avec les demandes Access Approval pour votre cluster.

    Pour obtenir les demandes Access Approval pour votre projet, consultez Afficher l'historique des demandes Access Approval. Access Approval peut être soumis à des exclusions.

  4. Vous pouvez également, valider la signature de l'approbation d'accès signée associée au journal Access Transparency.

Détails des journaux d'accès au plan de contrôle

Cette section fournit des détails et des exemples des journaux d'accès au plan de contrôle que GKE génère lorsque le personnel de Google se connecte à vos instances de plan de contrôle.

Journaux de connexion au plan de contrôle

GKE ajoute un journal de connexion au plan de contrôle pour chaque nouvelle connexion réseau entrante à une instance de plan de contrôle. Ces journaux incluent des détails spécifiques tels que les suivants :

  • Adresses IP et ports source et de destination
  • Direction et protocole de la connexion

Voici un exemple de journal de connexion au plan de contrôle :

{
  insertId: "z1eq8wonio335a5h",
  jsonPayload: {
    instance: {
      vm_name: "gke-dee49f0d6fa34ce3a2ac-f513-d195-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "CLUSTER_ID",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1-c/clusters/CLUSTER_NAME"
    },
    connection: {
      state: "NEW",
      src_ip: "192.0.2.100",
      src_port: 32774,
      dest_ip: "203.0.113.12",
      dest_port: 22,
      direction: "INGRESS"
      protocol: "TCP"
    },
  }
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection",
  receiveTimestamp: "2024-04-11T04:08:01.883070399Z",
  resource: {
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1-c",
      project_id: "PROJECT_ID"
    }
    type: "gke_cluster",
  }
  severity: "NOTICE",
  timestamp: "2024-04-11T04:07:59.019330Z"
}

Les champs suivants de l'entrée de journal sont pertinents pour vérifier les actions de Google :

  • cluster.cluster_urn : identifiant de ressource complet du cluster. Cet identifiant est au format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, avec les variables suivantes :

    • PROJECT_NUMBER: identifiant numérique du projet de vos clusters.
    • LOCATION : emplacement de votre cluster. Cloud de Confiance
    • CLUSTER_NAME : nom de votre cluster.

  • connection : détails sur la tentative de connexion. Ce champ contient les informations suivantes :

    • state : état de la connexion. Pour les nouvelles connexions, la valeur est NEW.
    • src_ip : adresse IP de la source de connexion.
    • src_port : numéro de port de la source de connexion.
    • dest_ip : adresse IP interne de votre VM de plan de contrôle.
    • dest_port : numéro de port de destination.
    • direction : direction de la connexion. La valeur est toujours INGRESS.
    • protocol : protocole IP, tel que TCP.

Journaux SSH du plan de contrôle

GKE ajoute des journaux SSH du plan de contrôle pour les événements liés aux connexions SSH aux instances de plan de contrôle. GKE enregistre les événements suivants :

  • Clé SSH acceptée pour un utilisateur
  • L'état de la session est passé de 0 à 1, ce qui indique que l'utilisateur s'est connecté
  • Session SSH ouverte
  • Session SSH fermée
  • L'état de la session est passé de 1 à 0, ce qui indique que l'utilisateur s'est déconnecté
  • Échec de la session SSH

Par exemple, le journal SSH du plan de contrôle suivant concerne l'ouverture d'une session SSH :

{
  insertId: "8llczemdulwbbwpa",
  jsonPayload: {
    instance: {
      vm_name: "gke-06cb920c609941c0a5ce-6840-40e9-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "891e6d12889747748c1ac16ffcc6cb7c0a96450b36864eb680917c119fd801d0",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1/clusters/CLUSTER_NAME",
    },
    message: "pam_unix(sshd:session): session opened for user REDACTED by (uid=0)",
  },
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-ssh",
  receiveTimestamp: "2024-04-09T13:21:55.231436462Z"
  resource: {
    type: "gke_cluster",
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1",
      project_id: "PROJECT_ID"
    }
  },
  severity: "NOTICE",
  timestamp: "2024-04-09T13:21:50.742246Z"
}

Les champs suivants de l'entrée de journal sont pertinents pour vérifier les actions de Google :

  • cluster.cluster_urn : identifiant de ressource complet du cluster. Cet identifiant est au format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, avec les variables suivantes :

    • PROJECT_NUMBER: identifiant numérique du projet de votre cluster.
    • LOCATION : emplacement de votre cluster. Cloud de Confiance
    • CLUSTER_NAME : nom de votre cluster.

  • message : détails sur la connexion SSH.

Désactiver les journaux d'accès au plan de contrôle

  1. Pour afficher les types de journaux spécifiques utilisés par votre cluster, exécutez la commande suivante :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    Le résultat ressemble à ce qui suit :

    SYSTEM_COMPONENTS,WORKLOADS,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

  2. Pour désactiver les journaux d'accès au plan de contrôle d'un cluster, exécutez la commande suivante :

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Dans l'option --logging, spécifiez les composants de journalisation à partir du résultat de la commande précédente. Cet exemple de commande désactive les journaux d'accès au plan de contrôle, mais laisse les autres journaux de composants du plan de contrôle activés.

Pour désactiver les composants de journalisation à l'aide de l'API GKE, définissez les valeurs correspondantes dans l'objet LoggingConfig de la ressource ClusterUpdate dans la projects.locations.clusters.update méthode.

Étape suivante