Activer les journaux auditd Linux sur les 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 détaillés peut fournir des informations précieuses sur l'état de votre cluster et de vos charges de travail, comme les messages d'erreur, les tentatives de connexion et les exécutions de binaires. Ces informations peuvent servir à résoudre des problèmes ou à mener des investigations sur des incidents de sécurité.

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.

Cette page s'adresse aux spécialistes de la sécurité qui examinent et analysent les journaux de sécurité. Utilisez ces informations pour comprendre les exigences et les limites des journaux OS détaillés, et pour guider votre implémentation lorsque vous les activez sur vos nœuds GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de connaître les journaux d'audit du système d'exploitation Linux.

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

Présentation

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é rétrospective. 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/troubleshooting/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. Notez que l'image fluent-bit utilisée dans cet exemple de fichier manifeste n'est fournie qu'à des fins de démonstration. Il est recommandé de remplacer l'image par une image provenant d'une source contrôlée avec un résumé SHA-256.

  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 des journaux

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

Désactiver les journaux

Pour désactiver la journalisation auditd sur vos nœuds, supprimez le DaemonSet de journalisation, puis déployez le DaemonSet cos-auditd-logging-disable pour rétablir les modifications apportées au service systemd sur chaque nœud. Une fois ce DaemonSet déployé, vous ne pouvez pas activer la journalisation auditd, sauf si les nœuds sont recréés.

  1. Supprimez le DaemonSet de journalisation d'origine et les ressources associées :

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. Appliquez le DaemonSet de nettoyage cos-auditd-logging-disable :

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. Vérifiez que les pods cleanup-auditd sont en cours d'exécution sur tous vos nœuds :

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    Attendez que tous les pods affichent l'état Running.

  4. Une fois les pods de nettoyage en cours d'exécution, vérifiez qu'aucun nouveau journal linux-auditd n'est généré en exécutant les requêtes de la section Déployer le DaemonSet de journalisation. Par exemple, vous pouvez utiliser la commande gcloud CLI suivante :

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

    Cette commande recherche les journaux des cinq dernières minutes. Si le nettoyage a réussi, le résultat est vide.

    De même, lorsque vous utilisez l'explorateur Cloud avec le même filtre, aucune nouvelle entrée de journal ne doit apparaître après l'heure de nettoyage.

  5. Supprimez le DaemonSet et l'espace de noms de nettoyage :

    kubectl delete -f cleanup-auditd-daemonset.yaml

    Cette commande supprime à la fois le DaemonSet et l'espace de noms cos-auditd.

Étapes suivantes