Activez, interrogez et configurez des alertes pour les journaux d'audit du serveur API afin de répondre aux exigences de conformité et de sécurité.
L'audit de cluster enregistre les requêtes et réponses du serveur API. Vous pouvez ainsi retracer l'historique des opérations et enquêter sur les anomalies.
S'applique aux clusters ACK managés, ACK dédiés et ACK Serverless.
Pour les clusters enregistrés, consultez la rubrique Utiliser l'audit de cluster .
Facturation
Les données des journaux d'audit sont facturées selon le modèle « paiement à la fonctionnalité ». Consultez les rubriques Consulter vos factures et Paiement à la fonctionnalité.
L'activation de l'audit de cluster engendre des coûts liés au service Simple Log Service (SLS). Surveillez le volume de vos journaux et définissez une période de rétention conforme à vos exigences. Par défaut : 30 jours pour les clusters ACK managés, 365 jours pour les clusters ACK dédiés.
Prérequis
Vérifiez que les quotas SLS suivants de votre compte Alibaba Cloud sont suffisants :
Quota de projet SLS
Quota de Logstore par projet SLS
Quota de tableau de bord par projet SLS
Consultez la rubrique Ajuster les quotas de ressources pour plus de détails sur les quotas et pour demander une augmentation.
Activer l'audit de cluster
Par défaut, l'option Enable Log Service est sélectionnée lors de la création du cluster. Si vous l'avez désactivée, suivez les étapes ci-dessous pour la réactiver.
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.
Sélectionnez un projet SLS et activez l'audit de cluster.
ACK crée automatiquement un Logstore nommé audit-${clustereid} dans le projet.
Ne modifiez pas les index par défaut. Toute modification empêcherait la génération correcte des rapports d'audit.
Consulter les rapports de journaux d'audit
ACK propose quatre rapports de journaux d'audit intégrés. Filtrez par namespace ou utilisateur RAM sur la page Cluster Auditing.
Ne modifiez pas les rapports de journaux d'audit intégrés. Créez plutôt des rapports personnalisés dans la console SLS.
Cliquez sur l'icône
de n'importe quel graphique pour l'afficher en plein écran ou prévisualiser son instruction de requête.
Vue d'ensemble
Affiche tous les événements du cluster et les détails des événements prioritaires, y compris les opérations des utilisateurs RAM, l'accès Internet, les exécutions de commandes, les suppressions de ressources, l'accès aux Secrets et les vulnérabilités CVE.
Vue d'ensemble des opérations
Fournit des statistiques sur les opérations de création, mise à jour, suppression et lecture pour les catégories suivantes :
Ressources de calcul : Deployment, StatefulSet, CronJob, DaemonSet, Job et Pod
Ressources réseau : Service et Ingress
Ressources de stockage : ConfigMap, Secret et PersistentVolumeClaim (PVC)
Ressources de contrôle d'accès : Role, ClusterRole, RoleBinding et ClusterRoleBinding

Détails des opérations
Affiche les opérations pour un type de ressource spécifique. Sélectionnez un type de ressource pour interroger les données. Le rapport affiche le nombre total, la distribution par namespace, le taux de réussite et les tendances dans le temps.
Pour interroger des ressources CRD ou des ressources non répertoriées, saisissez le nom de la ressource au pluriel. Par exemple, pour interrogerAliyunLogConfig, saisissezAliyunLogConfigs.
Vulnérabilités CVE
Affiche les vulnérabilités CVE de Kubernetes. Filtrez par ID d'utilisateur RAM. Consultez la rubrique [[Sécurité CVE] Corrections des vulnérabilités CVE](t96487.xdita#) pour les mesures correctives.
Interroger les données détaillées des journaux
Pour des requêtes personnalisées et une analyse approfondie, accédez aux données brutes des journaux d'audit dans la console SLS.
Rétention par défaut : 30 jours pour les clusters ACK managés, 365 jours pour les clusters ACK dédiés. Consultez la rubrique Gérer un Logstore pour modifier la période de rétention.
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, cliquez sur Cluster Information.
Dans l'onglet Cluster Resources, cliquez sur l'ID du projet situé à côté de Log Service Project. Dans la liste des Logstores, cliquez sur le Logstore nommé audit-${clustereid}.
Saisissez une instruction de requête, configurez la plage de temps de la requête (par exemple, les 15 dernières minutes) et cliquez sur Search & Analysis.
Modèles de requête courants :
Par utilisateur RAM : Saisissez l'ID de l'utilisateur RAM.
Par ressource : Saisissez le nom de la ressource (Deployment, Service, ConfigMap, etc.).
-
Exclure les composants système : Filtrez le bruit généré par les composants système :
NOT user.username: node NOT user.username: serviceaccount NOT user.username: apiserver NOT user.username: kube-scheduler NOT user.username: kube-controller-manager
Consultez la rubrique Méthodes de requête pour plus de détails sur la syntaxe.
Configurer les alertes
Configurez des règles d'alerte SLS pour recevoir des notifications en temps réel lorsque des opérations spécifiques se produisent. Les méthodes prises en charge incluent les chatbots DingTalk, les webhooks personnalisés et le centre de messages Alibaba Cloud.
Consultez la rubrique Configurer une règle d'alerte dans SLS.
Exemple d'alerte 1 : Commandes exécutées dans les conteneurs
Alerte lorsqu'un utilisateur exécute des commandes dans des conteneurs. Chaque alerte inclut le conteneur, la commande, l'utilisateur, l'ID d'événement, l'heure et l'adresse IP source.
Exemple d'instruction de requête :
verb : create and objectRef.subresource:exec and stage: ResponseStarted | SELECT auditID as "Event ID", date_format(from_unixtime(__time__), '%Y-%m-%d %T' ) as "Time", regexp_extract("requestURI", '([^\?]*)/exec\?.*', 1)as "Resource", regexp_extract("requestURI", '\?(.*)', 1)as "Command" ,"responseStatus.code" as "Status code",
CASE
WHEN "user.username" != 'kubernetes-admin' then "user.username"
WHEN "user.username" = 'kubernetes-admin' and regexp_like("annotations.authorization.k8s.io/reason", 'RoleBinding') then regexp_extract("annotations.authorization.k8s.io/reason", ' to User "(\w+)"', 1)
ELSE 'kubernetes-admin' END
as "User account",
CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END
as "Source IP address" order by "Time" desc limit 10000
Expression de condition : Event =~ ".*"
Exemple d'alerte 2 : Échec d'accès Internet depuis le serveur API
Surveille les requêtes Internet sortantes depuis votre cluster. L'alerte se déclenche lorsque le nombre de requêtes atteint 10 et que le taux d'échec dépasse 50 %.
Exemple d'instruction de requête :
* | select ip as "Source IP address", total as "Number of times of Internet access", round(rate * 100, 2) as "Failure rate in percentage", failCount as "Number of times of illegal access", CASE when security_check_ip(ip) = 1 then 'yes' else 'no' end as "Whether the IP address is risky", ip_to_country(ip) as "Country", ip_to_province(ip) as "Province", ip_to_city(ip) as "City", ip_to_provider(ip) as "ISP" from (select CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END
as ip, count(1) as total,
sum(CASE WHEN "responseStatus.code" < 400 then 0
ELSE 1 END) * 1.0 / count(1) as rate,
count_if("responseStatus.code" = 403) as failCount
from log group by ip limit 10000) where ip_to_domain(ip) != 'intranet' and ip not LIKE '%,%' and not try(is_subnet_of('7.0.0.0/8', ip)) ORDER by "Number of times of Internet access" desc limit 10000
Expression de condition : Source IP address =~ ".*"
Gérer les paramètres d'audit de cluster
Modifier le projet SLS
Pour migrer les journaux d'audit vers un autre projet SLS :
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.
Cliquez sur Change Log Service Project et suivez les instructions.
Désactiver l'audit de cluster
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.
Cliquez sur Disable Cluster Auditing.
Utiliser un service de journalisation tiers (clusters ACK dédiés uniquement)
SLS est le stockage recommandé pour les journaux d'audit. Pour utiliser un service de journalisation tiers, ignorez SLS lors de la création du cluster et intégrez le service tiers. Les journaux d'audit bruts sont disponibles sur les nœuds maîtres à l'emplacement /var/log/kubernetes/kubernetes.audit au format JSON.
Politique d'audit et configuration du backend (clusters ACK dédiés)
Pour les clusters ACK dédiés, l'option Enable Log Service est sélectionnée par défaut. Les événements d'audit sont collectés selon la politique d'audit et écrits dans le système de fichiers de journalisation du backend.
Politique d'audit
La politique d'audit définit les événements à collecter et leur niveau de détail. Il existe quatre niveaux d'audit :
|
Niveau d'audit |
Éléments collectés |
|
Aucun |
Rien. Les événements correspondants sont ignorés. |
|
Métadonnées |
Métadonnées de la requête uniquement, telles que les informations utilisateur et les horodatages. Aucun corps de requête ou de réponse. |
|
Requête |
Métadonnées et corps de la requête. Aucun corps de réponse. Les requêtes hors ressource sont exclues. |
|
RequestResponse |
Métadonnées, corps de la requête et corps de la réponse. Les requêtes hors ressource sont exclues. |
La politique d'audit est chargée depuis /etc/kubernetes/audit-policy.yml sur les nœuds maîtres (via l'indicateur --audit-policy-file). Politique ACK par défaut :
apiVersion: audit.k8s.io/v1 # Required. Set to audit.k8s.io/v1 if the Kubernetes version of the cluster is 1.24 or later and set to audit.k8s.io/v1beta1 if the Kubernetes version of the cluster is earlier than 1.24.
kind: Policy
# No need to generate audit events at the RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# The following types of requests are frequent and the risk of these requests is low. We recommend that you set the rule to None to skip these requests.
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core
resources: ["endpoints", "services"]
- level: None
users: ["system:unsecured"]
namespaces: ["kube-system"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["configmaps"]
- level: None
users: ["kubelet"] # legacy kubelet identity
verbs: ["get"]
resources:
- group: "" # core
resources: ["nodes"]
- level: None
userGroups: ["system:nodes"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["nodes"]
- level: None
users:
- system:kube-controller-manager
- system:kube-scheduler
- system:serviceaccount:kube-system:endpoint-controller
verbs: ["get", "update"]
namespaces: ["kube-system"]
resources:
- group: "" # core
resources: ["endpoints"]
- level: None
users: ["system:apiserver"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["namespaces"]
# Set the rule to None for read-only URLs, such as /healthz*, /version*, and /swagger*.
- level: None
nonResourceURLs:
- /healthz*
- /version
- /swagger*
# Set the rule to None for events.
- level: None
resources:
- group: "" # core
resources: ["events"]
# Set the rule to Metadata for Secrets, ConfigMaps, and TokenReview API requests that may contain sensitive information or binary files.
- level: Metadata
resources:
- group: "" # core
resources: ["secrets", "configmaps"]
- group: authentication.k8s.io
resources: ["tokenreviews"]
# Responses may contain large amounts of data. Set the rule to Request so that the response body is not collected.
- level: Request
verbs: ["get", "list", "watch"]
resources:
- group: "" # core
- group: "admissionregistration.k8s.io"
- group: "apps"
- group: "authentication.k8s.io"
- group: "authorization.k8s.io"
- group: "autoscaling"
- group: "batch"
- group: "certificates.k8s.io"
- group: "extensions"
- group: "networking.k8s.io"
- group: "policy"
- group: "rbac.authorization.k8s.io"
- group: "settings.k8s.io"
- group: "storage.k8s.io"
# The rule is set to RequestResponse by default for known Kubernetes API requests to collect the request and response bodies.
- level: RequestResponse
resources:
- group: "" # core
- group: "admissionregistration.k8s.io"
- group: "apps"
- group: "authentication.k8s.io"
- group: "authorization.k8s.io"
- group: "autoscaling"
- group: "batch"
- group: "certificates.k8s.io"
- group: "extensions"
- group: "networking.k8s.io"
- group: "policy"
- group: "rbac.authorization.k8s.io"
- group: "settings.k8s.io"
- group: "storage.k8s.io"
# The rule is set to Metadata by default for other requests.
- level: Metadata
Comportements clés :
Les journaux sont générés après l'envoi des en-têtes de réponse, et non lors de la réception des requêtes.
Les requêtes watch de kube-proxy, les requêtes GET de kubelet et
system:nodesvers les nœuds, les opérations d'endpoint kube-system et les requêtes GET du serveur API vers les namespaces sont exclus.Les opérations de lecture (
get,list,watch) pour les APIauthentication,rbac,certificates,autoscalingetstoragesont journalisées au niveauRequest. Les opérations d'écriture sur ces API sont journalisées au niveauRequestResponse.Les Secrets et ConfigMaps sont journalisés uniquement au niveau
Metadata, de sorte que leur contenu n'est jamais écrit dans les journaux d'audit.
Backend d'audit
Les événements d'audit sont écrits sous forme de fichiers JSON dans le système de fichiers local des nœuds maîtres. La configuration du serveur API située à /etc/kubernetes/manifests/kube-apiserver.yaml contrôle le comportement du backend avec les indicateurs suivants :
|
Indicateur |
Description |
Valeur par défaut |
|
|
Nombre maximal de fichiers journaux tournants à conserver |
|
|
|
Taille maximale par fichier journal avant rotation |
|
|
|
Chemin de sortie pour les fichiers journaux d'audit |
|
|
|
Période de rétention des fichiers journaux tournants |
|
|
|
Chemin vers le fichier de politique d'audit |
|
Étapes suivantes
Consultez la rubrique Activer l'audit des conteneurs pour auditer les commandes
kubectl execdans les conteneurs.Consultez la rubrique Meilleures pratiques de sécurité pour la sécurité en entreprise.