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

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

Les journaux Access Transparency enregistrent les actions effectuées par le personnel de Google lors de l'accès à votre contenu. Ce guide s'adresse aux administrateurs de sécurité qui souhaitent vérifier le contenu des journaux Access Transparency et les approbations d'accès associées en les corrélant avec des sources de journalisation supplémentaires de GKE. Cette validation est entièrement facultative et n'est pas nécessaire 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 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 la section À 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 de fiabilité du site 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 client et la 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 la section 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 utiliser pour faire des recoupements avec les journaux d'audit générés par Access Transparency et par 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 de plan de contrôle (les clusters régionaux comptent 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 correspondre ces journaux 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 étaient le résultat d'un accès administratif autorisé par le personnel de Google. Lorsque vous activez l'autorité du plan de contrôle GKE pour votre cluster, tous les accès SSH du personnel Google à votre plan de contrôle sont non interactifs, ce qui 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.

  • Activez l'API Cloud Logging.

    Enable the API

  • Activez Access Transparency pour votre organisation. Pour obtenir des instructions, consultez la section Activer Access Transparency.

  • Vous pouvez également activer l'approbation des accès pour votre projet et sélectionner le service GKE. Pour obtenir des instructions, 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 d'autorité du plan de contrôle GKE. Pour activer ces fonctionnalités, contactez votre équipe commerciale Google Cloud .

Conditions requises

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

Rôles et autorisations requis

Pour obtenir les autorisations nécessaires pour activer la génération de journaux, et pour y accéder 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 la page 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 du 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 la section 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 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 de 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 des 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 du 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'indicateur --logging de 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 à côté 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 de gcloud CLI pour l'indicateur --logging qui correspondent à la configuration du composant de journalisation à partir de la sortie de l'étape précédente. Pour obtenir la liste des valeurs de 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 que votre cluster utilise déjà, séparés par une virgule. Assurez-vous de spécifier les valeurs de la gcloud CLI qui correspondent à ces composants de journalisation, tirés du tableau Journaux disponibles.

    • KCP_ACCESS_LOGS: liste des types de journaux d'accès du 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 du 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 méthode projects.locations.clusters.update, définissez les valeurs existantes et des nouveaux composants de journalisation dans l'objet LoggingConfig de la ressource ClusterUpdate.

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

Prenons un cluster pour lequel la commande gcloud container clusters describe a 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 du 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 du plan de contrôle, les journaux SSH du plan de contrôle et les journaux Access Transparency de 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 du 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")

La sortie 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

La vérification principale consiste à vérifier si tous les types de journaux pour toutes les connexions SSH s'affichent 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 du plan de contrôle et à un ou plusieurs journaux SSH. Ces journaux sont destinés aux actions effectuées par des humains 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 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 période de 15 minutes avant l'horodatage du journal SSH. Cette période tient compte de la fermeture finale de la session SSH qui se produit plusieurs minutes après la connexion initiale enregistrée par Access Transparency.
  2. Pour chaque journal de connexion du plan de contrôle, vérifiez si un journal Access Transparency existe dans une période de cinq minutes avant l'horodatage du journal de connexion du 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 aux demandes d'approbation des accès pour votre cluster.

    Pour obtenir des demandes d'autorisation d'accès pour votre projet, consultez la section Afficher l'historique des demandes d'autorisation d'accès. L'approbation des accès peut être soumise à 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 du journal d'accès au plan de contrôle

Cette section fournit des informations 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 du plan de contrôle

GKE ajoute un journal de connexion du 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 de la connexion et protocole

L'exemple suivant est un journal de connexion du 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 a le 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: emplacement Google Cloud de votre cluster.
    • CLUSTER_NAME : nom du 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, comme 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 correspond à 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 a le format //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, avec les variables suivantes:

    • PROJECT_NUMBER: numéro numérique de votre projet de cluster.
    • LOCATION: emplacement Google Cloud 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 du 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 du plan de contrôle, mais maintient 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.

Étape suivante