Cette page a été traduite par l'API Cloud Translation.

Règle d'audit

Cette page décrit la stratégie des journaux d'audit pour Google Kubernetes Engine (GKE). Pour obtenir des instructions sur l'activation et l'affichage des différents types de journaux d'audit, ainsi que sur les autorisations IAM requises, consultez la section Informations concernant les journaux d'audit de GKE.

Avant de commencer

Avant de lire ce document, assurez-vous de connaître les sujets suivants :

Présentation

Dans un cluster GKE, le serveur d'API Kubernetes écrit les entrées du journal d'audit dans un backend géré par GKE. Lorsque GKE reçoit des entrées de journal du serveur d'API Kubernetes, il les écrit dans le journal d'activité d'administration et le journal d'accès aux données de votre projet.

Deux stratégies influencent ce que vous voyez dans les journaux d'audit de votre projet :

La stratégie d'audit Kubernetes, qui définit les règles pour lesquelles des événements sont enregistrés en tant qu'entrées de journal. Elle spécifie également les données que les entrées de journal doivent inclure.
La stratégie d'audit GKE détermine les entrées à écrire dans votre journal d'activité d'administration et celles à enregistrer dans votre journal d'accès aux données.

Les journaux d'audit écrits dans votre journal d'accès aux données dépendent de la configuration de votre journal d'audit. Les journaux d'accès aux données utilisent les tarifs d'observabilité de Google Cloud. Les journaux d'activité d'administration sont gratuits. GKE est compatible avec les types de journaux d'accès aux données suivants.

ADMIN_READ : opérations de lecture des métadonnées sur les ressources Kubernetes (par exemple, lister les pods).
DATA_READ : opérations de lecture de données dans les ressources Kubernetes (par exemple, lire les journaux pour un pod).
DATA_WRITE : opérations d'écriture de données sur les ressources Kubernetes (par exemple, mettre à jour l'état des pods).

Pour en savoir plus, consultez la section Configurer les journaux d'audit des accès aux données.

Stratégie d'audit Kubernetes

Le serveur d'API Kubernetes suit une stratégie spécifiée dans l'option --audit-policy-file de la commande kube-apiserver.

Lorsque GKE démarre le serveur d'API Kubernetes, il fournit un fichier de stratégie d'audit en définissant la valeur de l'option --audit-policy-file. Dans le dépôt Kubernetes Open Source, vous pouvez voir le script configure-helper.sh, qui génère le fichier de stratégie d'audit. Vous pouvez voir l'essentiel du fichier de stratégie d'audit en consultant directement le script.

Événements et étapes

Lorsqu'une personne ou un composant adresse une requête au serveur d'API Kubernetes, la demande passe par une ou plusieurs étapes :

Étape	Description
RequestReceived	Le gestionnaire d'audit a reçu la requête.
ResponseStarted	Les en-têtes de réponse ont été envoyés, mais pas le corps de la réponse.
ResponseComplete	Le corps de la réponse est terminé et aucun octet supplémentaire ne sera envoyé.
Panic	Une erreur de serveur interne s'est produite et la requête n'a pas abouti.

Chaque étape d'une requête génère un événement qui est traité conformément à une stratégie. La stratégie spécifie si l'événement doit être enregistré en tant qu'entrée de journal et, le cas échéant, quelles données doivent être incluses dans l'entrée de journal.

Niveaux d'audit

Le fichier de stratégie d'audit Kubernetes contient une liste de règles. Dans le fichier de stratégie, la première règle correspondant à un événement définit le niveau d'audit pour l'événement.

Une règle peut spécifier l'un des niveaux d'audit suivants :

Niveau	Description
None	Ne créez pas d'entrée de journal pour l'événement.
Metadata	Créez une entrée de journal. Incluez des métadonnées, mais n'incluez pas le corps de la demande ni celui de la réponse.
Request	Créez une entrée de journal. Incluez les métadonnées et le corps de la requête, mais n'incluez pas le corps de la réponse.
RequestResponse	Créez une entrée de journal. Incluez les métadonnées, le corps de la requête et celui de la réponse.

Voici un exemple de règle. Si un événement correspond à la règle, le serveur d'API Kubernetes crée une entrée de journal au niveau Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Un événement correspond à la règle si toutes les conditions suivantes sont remplies :

L'événement ne correspond à aucune règle précédente du fichier de stratégie.
L'identité effectuant l'appel se trouve dans le groupe d'utilisateurs system:nodes.
L'appel est une requête update ou une requête patch.
La requête porte sur une ressource nodes/status ou pods/status.
L'événement n'est pas destiné à l'étape RequestReceived de l'appel.

Résumé de la stratégie d'audit Kubernetes pour les clusters GKE

En général, les requêtes d'écriture telles que create, update et delete sont consignées au niveau RequestResponse.
En général, les événements get, list et watch sont consignés au niveau Metadata.
Certains événements sont traités comme des cas particuliers. Pour une liste définitive des requêtes traitées en tant que cas particuliers, consultez le script de la stratégie. Au moment de la rédaction de ce document, vous trouverez les cas particuliers suivants :
- Les requêtes de mise à jour et de correctif effectuées par kubelet, system:node-problem-detector ou system:serviceaccount:kube-system:node-problem-detector sur une ressource nodes/status ou pods/status sont consignées au niveau "Request".
- Les requêtes de mise à jour et de correctif effectuées par n'importe quelle identité du groupe system:nodes sur une ressource nodes/status ou pods/status sont consignées au niveau "Request".
- Les requêtes deletecollection effectuées par system:serviceaccount:kube-system:namespace-controller sont consignées au niveau "Request".
- Les requêtes sur une ressource secrets, configmaps ou tokenreviews sont consignées au niveau "Metadata".
Certaines requêtes ne sont pas du tout enregistrées. Pour obtenir la liste définitive des requêtes non consignées, consultez les règles level: None dans le script de la stratégie. Au moment de la rédaction de ce document, voici les requêtes qui ne sont pas consignées :
- Les requêtes de system:kube-proxy pour surveiller une ressource endpoints, services ou services/status
- Les requêtes Get de system:unsecured sur une ressource configmaps dans l'espace de noms kube-system
- Les requêtes Get de kubelet sur une ressource nodes ou nodes/status
- Les requêtes Get de n'importe quelle identité dans le groupe system:nodes sur une ressource nodes ou nodes/status
- Les requêtes Get et Update de system:kube-controller-manager, system:kube-scheduler ou system:serviceaccount:endpoint-controller sur une ressource endpoints dans l'espace de noms kube-system
- Les requêtes Get de system:apiserver sur une ressource namespaces, namespaces/status ou namespaces/finalize
- Les requêtes Get et List de system:kube-controller-manager sur n'importe quelle ressource du groupe metrics.k8s.io
- Les requêtes vers des URL qui correspondent à /healthz*, /version ou /swagger*

Stratégie d'audit GKE

Lorsque GKE reçoit des entrées de journal du serveur d'API Kubernetes, il applique sa propre stratégie pour déterminer les entrées à écrire dans le journal d'activité d'administration de votre projet et celles à écrire dans le journal d'accès aux données de votre projet.

Dans la plupart des cas, GKE applique les règles suivantes pour consigner les entrées provenant du serveur d'API Kubernetes :

Les entrées représentant des requêtes create,delete et update sont consignées dans votre journal des activités d'administration.
Les entrées représentant des requêtes get,list et updateStatus sont consignées dans votre journal d'accès aux données.

Pour vous renseigner en détail sur les tarifs et les types de journaux activés par défaut, consultez la page Informations sur Logging.

Comprendre le fichier de stratégie d'audit Kubernetes

Pour les clusters GKE, le fichier de stratégie d'audit Kubernetes commence par des règles spécifiant que certains événements ne doivent pas être consignés du tout. Par exemple, cette règle indique que toute requête get de kubelet sur une ressource nodes ou nodes/status ne doit pas être consignée. Rappelez-vous qu'un niveau None signifie qu'aucun événement correspondant ne doit être consigné :

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Après la liste des règles level: None, le fichier de stratégie contient une liste de règles constituant des cas particuliers. Par exemple, voici une règle de cas particulier qui indique de consigner certaines requêtes au niveau Metadata :

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Un événement correspond à la règle si toutes les conditions suivantes sont remplies :

L'événement ne correspond à aucune règle précédente du fichier de stratégie.
La requête porte sur une ressource de type secrets, configmaps ou tokenreviews.
L'événement n'est pas destiné à l'étape RequestReceived de l'appel.

En plus de la liste des règles de cas particuliers, le fichier de règles contient des règles générales. Pour consulter les règles générales du script, vous devez remplacer la valeur de known_apis par ${known_apis}. Après le remplacement vous obtenez une règle identique à ce qui suit :

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La règle s'applique aux événements qui ne correspondent à aucune règle précédente du fichier de stratégie et qui ne se trouvent pas à l'étape RequestReceived. La règle indique que les requêtes get, list et watch sur toute ressource appartenant à l'un des groupes répertoriés doivent être consignées au niveau Request.

La règle suivante du fichier de stratégie ressemble à ce qui suit :

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La règle s'applique aux événements qui ne correspondent à aucune règle précédente du fichier de stratégie et qui ne se trouvent pas à l'étape RequestReceived. En particulier, la règle ne s'applique pas aux requêtes de lecture : get, list et watch. Au lieu de cela, elles s'applique aux requêtes d'écriture telles que create, update et delete. La règle indique que les requêtes d'écriture doivent être consignées au niveau RequestResponse.