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

Cette page explique comment vérifier les connexions établies par le personnel Google au 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 s'adresse aux administrateurs de sécurité qui souhaitent obtenir une vérification supplémentaire du contenu des journaux Access Transparency et des approbations Access Approval associées en les corrélant avec d'autres sources de journaux de GKE. Cette validation 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 l'une des fonctionnalités facultatives du plan de contrôle dans GKE. Elle vous permet d'effectuer des tâches telles que la vérification de la stratégie de sécurité de votre 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 l'autorité du plan de contrôle GKE.

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

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

Lors de sessions de dépannage ou pour d'autres raisons commerciales justifiées, le personnel Google, comme les ingénieurs en fiabilité des sites et les employés du Cloud Customer Care, peut avoir besoin d'un accès administrateur aux instances Compute Engine qui hébergent votre plan de contrôle. Selon votre formule d'assistance Customer Care et 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 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 l'autorité du plan de contrôle GKE, 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 ajoute des journaux d'accès au plan de contrôle au bucket _Default dans Logging pour enregistrer les connexions réseau entrantes et les événements SSH spécifiques dans vos instances de plan de contrôle. Vous devez activer l'autorité du plan de contrôle GKE 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 du plan de contrôle dépend de facteurs tels que le nombre de nœuds du cluster, le nombre d'instances du plan de contrôle (les clusters régionaux comportent plus d'instances de plan de contrôle 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. Cela vous permet de confirmer que toutes les connexions SSH à vos instances de plan de contrôle ont été établies à la suite d'un accès administratif autorisé par le personnel Google. Lorsque vous activez l'autorité du plan de contrôle GKE pour votre cluster, tout accès SSH au plan de contrôle par le personnel Google est non interactif. Cela signifie que chaque connexion SSH exécute une seule commande que vous autorisez.

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 Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

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, et pour accéder aux journaux et les traiter, demandez à votre administrateur de vous accorder 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 avec 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.

Voici les noms des composants de journalisation compatibles pour les journaux d'accès au plan de contrôle :

  • Journaux SSH du plan de contrôle : KCP_SSHD
  • Journaux de connexion du 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 dans lequel créer le cluster.

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

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, vous devez procéder comme suit :

  1. Recherchez les composants de journalisation existants utilisés par votre cluster.
  2. Identifiez les valeurs correspondantes à spécifier dans l'indicateur --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'indicateur --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 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 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 des composants de journalisation séparés par une virgule que votre cluster utilise déjà. Assurez-vous de spécifier les valeurs gcloud CLI qui correspondent à ces composants de journalisation, tirées du tableau Journaux disponibles.

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

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

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

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

Prenons l'exemple d'un cluster pour lequel la commande gcloud container clusters describe présente la configuration de journalisation suivante :

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

La commande de mise à jour du cluster suivante active les deux types de journaux d'accès au plan de contrôle tout en conservant la configuration de journal 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

Comparer 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 console Google Cloud , 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 du plan de contrôle
  • Journaux SSH pour chaque session SSH

Effectuer des vérifications de validation

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 de journalisation de la section précédente. Chaque journal Access Transparency doit être associé à un journal de connexion au plan de contrôle et à un ou plusieurs journaux SSH. Ces journaux concernent les actions effectuées par des utilisateurs dans vos instances de plan de contrôle. Le volume de journaux devrait donc être faible.

Vous pouvez également effectuer les vérifications supplémentaires suivantes sur le contenu du journal :

  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 le code temporel du journal SSH. Cette période tient compte de la fermeture de la session SSH finale, 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 s'il existe un journal Access Transparency dans une fenêtre de cinq minutes avant le code temporel 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. Comparez ce champ avec les demandes Approval Access pour votre cluster.

    Pour obtenir les demandes Access Approval pour votre projet, consultez Afficher l'historique des demandes Access Approval. Access Approval peut faire l'objet d'exclusions.

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

Détails du journal d'accès au plan de contrôle

Cette section fournit des détails et des exemples de 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 du 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 informations spécifiques, comme les suivantes :

  • Adresses IP et ports source et de destination
  • Sens 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 utiles 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 : numéro de projet numérique de votre projet de clusters.
    • LOCATION : Google Cloud emplacement de votre cluster.
    • CLUSTER_NAME : nom du cluster

  • connection : détails de 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 du 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é avec succès.
  • 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 une session SSH en cours d'ouverture :

{
  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 utiles 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 : numéro de projet numérique de votre projet de cluster.
    • LOCATION : Google Cloud emplacement de votre cluster.
    • CLUSTER_NAME : nom du cluster

  • message : informations 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 pour 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'indicateur --logging, spécifiez les composants de journalisation à partir de la sortie de la commande précédente. Cet exemple de commande désactive les journaux d'accès au plan de contrôle, mais conserve les autres journaux des 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 méthode projects.locations.clusters.update.

Étapes suivantes