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 l'agent Logging pour envoyer des journaux à la suite des opérations Google Cloud.

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

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 à Stackdriver 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.

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. Le deuxième conteneur, fluentd-gcp-cos-auditd, est destiné à l'agent Logging de la suite des opérations Google Cloud, une application basée sur fluentd.

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, fluentd-gcp-config-cos-auditd. L'exemple fourni envoie des journaux d'audit à la suite des opérations Google Cloud, mais vous pouvez le configurer pour envoyer des journaux à des destinations autres que la suite des opérations Google Cloud.

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. Déployez le DaemonSet de journalisation et le ConfigMap :

    kubectl apply -f cos-auditd-logging.yaml
    
  5. 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.

  6. Vous pouvez désormais accéder aux journaux d'audit dans la suite des opérations Google Cloud. Dans la Visionneuse de journaux, filtrez les résultats par instance de VM.

Exporter les journaux

Pour savoir comment exporter des journaux, consultez les ressources suivantes :

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