Présentation
Ce document explique comment utiliser Cloud Audit Logs pour Google Distributed Cloud (logiciel uniquement). Google Distributed Cloud utilise la journalisation d'audit Kubernetes, qui conserve un enregistrement chronologique des appels passés vers le serveur de l'API Kubernetes d'un cluster. Les journaux d'audit sont utiles pour analyser les requêtes API suspectes et collecter des statistiques. Pour en savoir plus sur la journalisation d'audit pour l'API GKE On-Prem, consultez Journaux d'audit des API Cloud.
À propos de Cloud Audit Logs
Les journaux d'audit sont écrits dans Cloud Audit Logs de votre projet Google Cloud . Écrire dans Cloud Audit Logs présente plusieurs avantages par rapport à l'écriture sur disque, voire à la capture de journaux dans un système de journalisation sur site :
- Les journaux d'audit de tous les clusters peuvent être centralisés.
- Les entrées de journal écrites dans Cloud Audit Logging sont immuables.
- Les entrées Cloud Audit Logging sont conservées pendant 400 jours.
- La fonctionnalité Cloud Audit Logs est incluse dans le prix de Google Distributed Cloud.
- Vous pouvez configurer Google Distributed Cloud pour écrire des journaux sur disque ou dans Cloud Audit Logs.
Journaux d'audit sur disque
Par défaut, les journaux d'audit sont écrits sur un disque persistant, de sorte que les redémarrages et les mises à niveau de la VM n'entraînent pas leur disparition.
Si le cluster avancé n'est pas activé :
Google Distributed Cloud conserve jusqu'à 12 Go d'entrées de journal d'audit.
Si l'agrégation avancée est activée
Google Distributed Cloud conserve jusqu'à 1 Go d'entrées de journal d'audit.
Cloud Audit Logs
Si vous activez Cloud Audit Logs pour un cluster, les entrées du journal d'audit pour les activités d'administration du serveur d'API Kubernetes du cluster sont envoyées à Google Cloud, à l'aide du projet Google Cloud que vous spécifiez dans le champcloudAuditLogging.projectIDdu fichier de configuration du cluster.
Ce projet Google Cloud est appelé projet de journalisation d'audit.
Votre projet de journalisation d'audit doit être identique au projet hôte de parc.
Pour mettre en mémoire tampon et écrire des entrées de journal dans Cloud Audit Logs, Google Distributed Cloud déploie un pod audit-proxy sur le cluster d'administrateur.
Ce composant est également disponible en tant que conteneur side-car sur les clusters d'utilisateur.
Limites
Cloud Audit Logs présente les limites suivantes :
- La journalisation des accès aux données (requêtes get, list et watch) n'est pas prise en charge.
- La modification de la stratégie d'audit Kubernetes n'est pas acceptée.
- Cloud Audit Logging n'est pas résilient aux pannes réseau étendues. Si les entrées de journal ne peuvent pas être exportées vers Google Cloud, elles sont mises en cache dans un tampon de disque de 10 Go. Si ce tampon est plein, les entrées les plus anciennes sont supprimées.
- Un projet peut accepter jusqu'à environ 1 000 comptes de service à utiliser avec Cloud Audit Logs. Plusieurs clusters peuvent utiliser le même compte de service.
Activer l'API Anthos Audit
Activez l'API Anthos Audit dans votre projet de journalisation d'audit.
Créer un compte de service pour Cloud Audit Logs
Vous disposez déjà d'un ou de plusieurs comptes de service que vous avez créés pour les utiliser avec Google Distributed Cloud. Pour cette fonctionnalité, vous devez créer un compte de service supplémentaire appelé compte de service de journalisation d'audit.
Créez votre compte de service de journalisation d'audit :
gcloud iam service-accounts create audit-logging-service-account
Créez un fichier de clé JSON pour votre compte de service Cloud Audit Logging :
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL
où AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL est l'adresse e-mail de votre compte de service.
Enregistrez
audit-logging-key.jsonsur le poste de travail administrateur au même emplacement que les autres clés de votre compte de service.
AVERTISSEMENT : Avant de supprimer ce compte de service, assurez-vous de le remplacer par le nouveau compte de service dans la configuration du cluster. La procédure est semblable à celle décrite dans Activer Cloud Audit Logs pour un cluster d'utilisateur existant. Si vous oubliez de le faire, suivez le guide de nettoyage.
Créer un cluster d'administrateur avec Cloud Audit Logs activé
Vous ne pouvez activer Cloud Audit Logs pour un cluster d'administrateur que lors de la création du cluster. Vous ne pouvez pas modifier un cluster d'administrateur existant pour activer Cloud Audit Logs.
Consultez la section Créer un cluster d'administrateur.
Dans votre fichier de configuration de cluster d'utilisateur, remplissez la section
cloudAuditLogging.Définissez
cloudAuditLogging.projectIDsur l'ID de votre projet de journalisation d'audit.Définissez
cloudAuditLogging.clusterLocationsur une région Google Cloud où vous souhaitez stocker les journaux d'audit. Pour une latence optimale, choisissez une région proche de votre centre de données sur site.Définissez
cloudAuditLogging.serviceAccountKeyPathsur le chemin d'accès du fichier de clé JSON pour votre compte de service de journalisation d'audit.
Exemple :
cloudAuditLogging:
projectID: "my-project"
clusterLocation: "us-west1"
serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Continuez de créer le cluster comme d'habitude.
Créer un cluster d'utilisateur avec Cloud Audit Logs activé
Consultez la section Créer un cluster d'utilisateur.
Dans votre fichier de configuration de cluster d'utilisateur, remplissez la section
cloudAuditLogging.Définissez
cloudAuditLogging.projectIDsur l'ID de votre projet de journalisation d'audit.Définissez
cloudAuditLogging.clusterLocationsur une région Google Cloud où vous souhaitez stocker les journaux d'audit. Pour une latence optimale, choisissez une région proche de votre centre de données sur site.Définissez
cloudAuditLogging.serviceAccounKeyPathsur le chemin d'accès du fichier de clé JSON de votre compte de service Cloud Audit Logging.Assurez-vous que la section
gkeConnectest renseignée et que la valeur degkeConnect.projectIDest identique àcloudAuditLogging.projectID.
Exemple :
gkeConnect:
projectID: "my-project"
registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"
cloudAuditLogging:
projectID: "my-project"
clusterLocation: "us-west1"
serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Continuez de créer le cluster comme d'habitude.
Activer Cloud Audit Logs pour un cluster d'utilisateur existant
Cloud Audit Logs ne peut être activé que dans le projet Google Cloud où le cluster d'utilisateur est enregistré.
Si un cluster d'utilisateur existant n'est pas enregistré, enregistrez-le en procédant comme suit avant d'activer Cloud Audit Logs :
Ajoutez une section
gkeConnectau fichier de configuration du cluster d'utilisateur. Exemple :gkeConnect: projectID: "my-project" registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"Mettez à jour le cluster :
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Une fois le cluster d'utilisateur enregistré, procédez comme suit pour activer Cloud Audit Logs :
Remplissez la section
cloudAuditLoggingdu fichier de configuration de votre cluster d'utilisateur. Consultez la section Créer un cluster utilisateur avec Cloud Audit Logs activé pour en savoir plus sur les champs individuels. L'élémentprojectIDde la sectioncloudAuditLoggingdoit être identique à celui de la sectiongkeConnect.Mettez à jour le cluster :
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Désactiver Cloud Audit Logs pour un cluster d'utilisateur existant
Dans le fichier de configuration du cluster d'utilisateur, supprimez la section
cloudAuditLogging.Mettez à jour le cluster d'utilisateur :
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
Accéder aux journaux d'audit
Journaux d'audit sur disque
Vous pouvez également trouver les journaux d'audit du cluster d'administrateur sur les nœuds du plan de contrôle sous /var/log/kube-audit/kube-apiserver-audit.log. Les journaux d'audit du cluster d'utilisateur se trouvent dans le fichier PersistentVolumeClaim nommé kube-audit-kube-apiserver-0. Vous pouvez accéder à ces données dans vos propres pods via des entrées volumes :
Ajoutez cette entrée pour le cluster d'administrateur :
volumes:
- name: kube-audit
hostPath:
path: /var/log/kube-audit
type: ""
Ajoutez cette entrée pour le cluster d'utilisateurs :
volumes:
- name: kube-audit
persistentVolumeClaim:
claimName: kube-audit-kube-apiserver-0
Pour planifier votre pod sur le nœud de cluster d'administrateur approprié (et uniquement pour ce nœud), vous devez ajouter les sections nodeSelector et tolerations à votre spécification de pod, comme suit :
spec:
nodeSelector:
node-role.kubernetes.io/master: ''
tolerations:
- key: node-role.kubernetes.io/master
value: ""
effect: NoSchedule
Pour le cluster d'utilisateur, définissez namespace comme nom du cluster d'utilisateur, puis définissez nodeName sur la même valeur que kube-apiserver-0 :
spec:
nodeName: NODE_NAME
Pour indiquer le nodeName de kube-apiserver-0, exécutez la commande suivante :
kubectl get pod kube-apiserver-0 -n USER_CLUSTER_NAME --kubeconfig kubeconfig -o jsonpath='{.spec.nodeName}'
Le nom de fichier de chaque journal d'audit comporte un horodatage qui correspond à la rotation du fichier. Un fichier contient les journaux d'audit jusqu'à cette date et cette heure.
Accéder à Cloud Audit Logs
Console
Dans la console Google Cloud , accédez à la page Explorateur de journaux du menu Journalisation.
Accéder à l'explorateur de journaux
Si la page Ancienne visionneuse de journaux s'ouvre, sélectionnez Mettre à niveau vers le nouvel explorateur de journaux dans le menu déroulant Mettre à niveau.
Cliquez dans le champ Requête pour saisir une requête.
Saisissez la requête suivante dans le champ Requête :
resource.type="k8s_cluster" logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" protoPayload.serviceName="anthosgke.googleapis.com"Remplacez
PROJECT_IDpar l'ID du projet.Cliquez sur Exécuter la requête pour afficher tous les journaux d'audit des clusters configurés pour se connecter à ce projet.
gcloud
- Répertoriez les deux premières entrées du journal d'activité d'administration de votre projet qui s'appliquent au type de ressource
k8s_cluster:
gcloud logging read \
'logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" \
AND resource.type="k8s_cluster" \
AND protoPayload.serviceName="anthosgke.googleapis.com" ' \
--limit 2 \
--freshness 300d
- Remplacez
PROJECT_IDpar l'ID du projet.
La sortie affiche deux entrées de journal. Notez que pour chaque entrée de journal, le champ logName a la valeur projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity et que protoPayload.serviceName est égal à anthosgke.googleapis.com.
Règle d'audit
La stratégie d'audit Kubernetes définit les règles pour lesquelles des événements sont enregistrés en tant qu'entrées de journal et spécifie les données que les entrées de journal doivent inclure. Le comportement de Cloud Audit Logs est déterminé par une règle de journalisation d'audit Kubernetes configurée de manière statique. Il n'est pas possible de modifier cette stratégie pour modifier le comportement de Cloud Audit Logs.