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.
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 à 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()
etmmap()
- 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 :
- Vous pouvez configurer des filtres dans le ConfigMap
cos-auditd-fluent-bit-config
afin que certaines données ne soient pas consignées. Reportez-vous à la documentation Fluent Bit sur les filtres Grep, Modify, Record Modifier et bien d'autres. - Vous pouvez également configurer Logging pour filtrer les journaux entrants. Pour en savoir plus, consultez la page Configurer et gérer des récepteurs.
Déployer le DaemonSet de journalisation
Vous pouvez utiliser un cluster existant ou en créer un autre.
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
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.
Initialisez des variables communes :
export CLUSTER_NAME=CLUSTER_NAME export CLUSTER_LOCATION=COMPUTE_REGION
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du clusterCOMPUTE_REGION
: région Compute Engine du cluster. Pour les clusters zonaux, utilisez plutôt la zone.
Déployez le Namespace, le DaemonSet et le ConfigMap de la journalisation :
envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \ | kubectl apply -f -
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.
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.
Supprimez le DaemonSet, le ConfigMap et leur espace de noms du cluster :
kubectl delete -f cos-auditd-logging.yaml
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
- Regardez la vidéo Cloud Forensics 101 pour faire vos premiers pas avec l'investigation dans le cloud.
- Apprenez-en plus sur la journalisation d'audit Kubernetes et la règle d'audit.
- Consultez la présentation des fonctionnalités de sécurité de Kubernetes Engine.
- Apprenez-en plus sur les journaux d'audit Cloud.