Activer les journaux d'audit Linux sur des nœuds GKE

Cette page explique comment activer les journaux d'audit détaillés du système d'exploitation sur les nœuds Google Kubernetes Engine exécutant Container-Optimized OS. Cette page explique également comment configurer un agent de journalisation Fluent Bit pour envoyer des journaux à Cloud Logging. L'activation des journaux auditd Linux n'est pas disponible dans les clusters GKE Autopilot, car Google gère les nœuds et les machines virtuelles (VM) sous-jacentes.

Les journaux d'audit du système d'exploitation sont différents des journaux d'audit Cloud et des journaux d'audit Kubernetes.

Aperçu

Les journaux du système d'exploitation sur vos nœuds fournissent de précieuses informations sur l'état de votre cluster et de vos charges de travail, par exemple des messages d'erreur, des tentatives de connexion et des exécutions de binaires. Ces informations peuvent servir à résoudre des problèmes ou à mener des investigations sur des incidents de sécurité.

Pour collecter les journaux de chaque nœud d'un cluster, utilisez un DaemonSet qui exécute exactement un pod sur chaque nœud du cluster où il peut être programmé. Ce pod configure le daemon de journalisation auditd sur l'hôte, et configure l'agent Logging de sorte qu'il envoie les journaux à Logging ou à tout autre service d'ingestion de journaux.

Par définition, l'audit se produit après un événement et constitue une mesure de sécurité post-mortem. Les journaux auditd seuls ne sont probablement pas suffisants pour mener des investigations sur votre cluster. Réfléchissez à la façon d'optimiser l'utilisation des journaux auditd dans le cadre de votre stratégie de sécurité globale.

Limites

Les mécanismes de journalisation décrits sur cette page ne fonctionnent que sur les nœuds exécutant Container-Optimized OS dans des clusters GKE Standard.

Fonctionnement du DaemonSet de journalisation

Cette section décrit le fonctionnement de l'exemple de DaemonSet de journalisation afin que vous puissiez le configurer en fonction de vos besoins. La section suivante explique comment déployer le DaemonSet.

L'exemple de fichier manifeste définit des objets DaemonSet et ConfigMap ainsi qu'un espace de noms pour les contenir.

Le DaemonSet déploie un pod sur chaque nœud du cluster. Le pod comporte deux conteneurs. Le premier est un conteneur d'initialisation qui lance le service systemd cloud-audit-setup disponible sur les nœuds Container-Optimized OS. Le second conteneur, cos-auditd-fluent-bit, contient une instance de Fluent Bit configurée pour collecter les journaux d'audit Linux à partir du journal de nœud et les exporter vers Cloud Logging.

L'exemple de DaemonSet de journalisation consigne les événements suivants :

  • Modifications de la configuration système d'auditd
  • Contrôles d'autorisation d'AppArmor
  • Exécutions de execve(), socket(), setsockopt() et mmap()
  • Connexions réseau
  • Connexions utilisateur
  • Session SSH et tous les autres TTY (y compris les sessions kubectl exec -t)

Configurer le DaemonSet de journalisation

Configurez le DaemonSet de journalisation à l'aide d'un ConfigMap, cos-auditd-fluent-bit-config. L'exemple fourni envoie des journaux d'audit à Logging, mais vous pouvez le configurer pour envoyer des journaux à d'autres destinations.

Le volume de journaux générés par auditd peut être très important et entraîner des coûts supplémentaires, car il consomme des ressources système et envoie plus de journaux que la configuration de journalisation par défaut. Vous pouvez configurer des filtres pour gérer le volume de journaux :

Déployer le DaemonSet de journalisation

  1. Vous pouvez utiliser un cluster existant ou en créer un autre.

  2. Téléchargez les exemples de fichiers manifestes :

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. Modifiez les exemples de fichiers manifestes en fonction de vos besoins. Reportez-vous à la section précédente pour en savoir plus sur le fonctionnement du DaemonSet.

  4. Initialisez des variables communes :

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • COMPUTE_REGION : région Compute Engine du cluster. Pour les clusters zonaux, utilisez plutôt la zone.

  5. Déployez le Namespace, le DaemonSet et le ConfigMap de la journalisation :

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. Vérifiez que les pods de journalisation ont démarré. Si vous avez défini un espace de noms différent dans vos fichiers manifestes, remplacez cos-auditd par le nom de l'espace de noms que vous utilisez.

    kubectl get pods --namespace=cos-auditd

    Si les pods sont en cours d'exécution, le résultat ressemble à ceci :

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    Un pod est déployé sur chaque nœud du cluster. Dans le cas présent, le cluster comporte trois nœuds.

  7. Vous pouvez désormais accéder aux journaux d'audit dans Logging. Dans l'explorateur de journaux, filtrez les résultats à l'aide de la requête suivante :

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    Vous pouvez également utiliser gcloud CLI (avec --limit, car l'ensemble de résultats peut être très volumineux) :

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

Exporter les journaux

Pour savoir comment acheminer vos journaux vers des destinations compatibles, consultez la page Configurer et gérer les récepteurs.

Nettoyage

Pour désactiver la journalisation auditd, supprimez le DaemonSet de journalisation et redémarrez les nœuds. Une fois activée, la configuration d'audit est verrouillée et ne peut être modifiée qu'en recréant le nœud.

  1. Supprimez le DaemonSet, le ConfigMap et leur espace de noms du cluster :

    kubectl delete -f cos-auditd-logging.yaml

  2. Redémarrez les nœuds du cluster. Commencez par récupérer le groupe d'instances auquel ils appartiennent :

    instance_group=$(gcloud compute instance-groups managed list \
                    --format="value(name)" \
                    --filter=${CLUSTER_NAME})

    Récupérez ensuite les instances proprement dites :

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
               --format="csv(instance)[no-heading][terminator=',']")

    Enfin, recréez les instances :

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
   --instances=${instances}

Étape suivante