Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Sécuriser les opérations du cluster avec l'audit du serveur API

Dernière mise à jour :Aug 31, 2026

Activez, interrogez et configurez des alertes sur les journaux d'audit du serveur API afin de répondre à vos 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 investiguer les anomalies.

S'applique aux clusters ACK managé, ACK dédié et ACK Serverless.

Pour les clusters enregistrés, consultez Utiliser l'audit de cluster .

Facturation

Les données des journaux d'audit suivent le modèle de facturation à la fonctionnalité. Consultez Consulter vos factures et Facturation à la fonctionnalité.

Important

L'activation de l'audit de cluster engendre des coûts Simple Log Service (SLS). Surveillez le volume de vos journaux et définissez une période de rétention adaptée à vos exigences de conformité. Valeurs par défaut : 30 jours pour les clusters ACK managé, 365 jours pour les clusters ACK dédié.

Prérequis

Vérifiez que les quotas SLS suivants sont suffisants dans votre compte Alibaba Cloud :

  • Quota de projets SLS

  • Quota de Logstores par projet SLS

  • Quota de tableaux de bord par projet SLS

Consultez Ajuster les quotas de ressources pour obtenir des détails sur les quotas et soumettre des demandes d'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 ces étapes pour la réactiver.

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.

  3. Sélectionnez un projet SLS et activez l'audit de cluster.

ACK crée automatiquement un Logstore nommé audit-${clustereid} dans le projet.

Important

Ne modifiez pas les index par défaut. Toute modification empêche la génération correcte des rapports d'audit.

Consulter les rapports de journaux d'audit

ACK fournit quatre rapports de journaux d'audit intégrés. Filtrez par namespace ou utilisateur RAM sur la page Cluster Auditing.

Important

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 image.png 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 ainsi que les détails des événements prioritaires, notamment les opérations des utilisateurs RAM, les accès Internet, les exécutions de commandes, les suppressions de ressources, les accès aux Secrets et les vulnérabilités CVE.

Aperçu 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

Operations overview

Détails des opérations

Présente les opérations pour un type de ressource spécifique. Sélectionnez un type de ressource à interroger. Le rapport affiche le nombre total, la répartition par namespace, le taux de réussite et les tendances dans le temps.

Pour interroger des ressources CRD ou non répertoriées, saisissez le nom de la ressource au pluriel. Par exemple, pour interroger AliyunLogConfig , saisissez AliyunLogConfigs .

Vulnérabilités CVE

Affiche les vulnérabilités CVE Kubernetes. Filtrez par ID d'utilisateur RAM. Consultez [[Sécurité CVE] Corrections des vulnérabilités CVE](t96487.xdita#) pour les mesures de remédiation.

Interroger les données de journal détaillées

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é, 365 jours pour les clusters ACK dédié. Consultez Gérer un Logstore pour modifier la période de rétention.
  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, cliquez sur Cluster Information.

  3. Dans l'onglet Cluster Resources, cliquez sur l'ID du projet en regard de Log Service Project. Dans la liste des Logstores, cliquez sur le Logstore nommé audit-${clustereid}.

  4. Saisissez une instruction de requête, configurez la plage temporelle (par exemple, les 15 dernières minutes), puis cliquez sur Search & Analysis.

Modèles de requêtes courants :

  • Par utilisateur RAM : saisissez l'ID de l'utilisateur RAM.

  • Par ressource : saisissez le nom de la ressource (Deployment, Service, ConfigMap ou similaire).

  • 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 Méthodes de requête pour plus de détails sur la syntaxe.

Configurer les alertes

Définissez des règles d'alerte SLS pour recevoir des notifications en temps réel lors d'opérations spécifiques. Les méthodes prises en charge incluent les chatbots DingTalk, les webhooks personnalisés et le centre de messages Alibaba Cloud.

Consultez Configurer une règle d'alerte dans SLS.

Exemple d'alerte 1 : Commandes exécutées dans des conteneurs

Alerte déclenchée lorsque des utilisateurs exécutent des commandes dans des conteneurs. Chaque alerte comprend 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 de 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 :

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.

  3. Cliquez sur Change Log Service Project et suivez les instructions.

Désactiver l'audit de cluster

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom du cluster. Dans le volet de gauche, choisissez Security > Cluster Auditing.

  3. Cliquez sur Disable Cluster Auditing.

Utiliser un service de journalisation tiers (clusters ACK dédié uniquement)

SLS constitue la solution recommandée pour le stockage des 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 dans /var/log/kubernetes/kubernetes.audit au format JSON.

Configuration de la politique d'audit et du backend (clusters ACK dédié)

Pour les clusters ACK dédié, 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 backend.

Politique d'audit

La politique d'audit définit les événements à collecter et leur niveau de détail. Quatre niveaux d'audit existent :

Niveau d'audit

Données collectées

None

Aucune. Les événements correspondants sont ignorés.

Metadata

Uniquement les métadonnées de la requête, telles que les informations utilisateur et les horodatages. Aucun corps de requête ou de réponse.

Request

Métadonnées et corps de la requête. Aucun corps de réponse. Requêtes hors ressources exclues.

RequestResponse

Métadonnées de la requête, corps de la requête et corps de la réponse. Requêtes hors ressources exclues.

La politique d'audit est chargée depuis /etc/kubernetes/audit-policy.yml sur les nœuds maîtres (via le paramètre --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 à la réception des requêtes.

  • Les requêtes watch de kube-proxy, les requêtes GET de kubelet et system:nodes vers les nœuds, les opérations sur les endpoints de kube-system, ainsi que les requêtes GET du serveur API vers les namespaces sont exclues.

  • Les opérations de lecture (get, list, watch) pour les API authentication, rbac, certificates, autoscaling et storage sont journalisées au niveau Request. Les opérations d'écriture sur ces API sont journalisées au niveau RequestResponse.

  • Les Secrets et ConfigMaps sont journalisés uniquement au niveau Metadata, leur contenu n'est donc 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 dans /etc/kubernetes/manifests/kube-apiserver.yaml contrôle le comportement du backend via les paramètres suivants :

Paramètre

Description

Valeur par défaut

--audit-log-maxbackup

Nombre maximal de fichiers de journaux archivés à conserver

10

--audit-log-maxsize

Taille maximale d'un fichier de journal avant rotation

100 Mo

--audit-log-path

Chemin de sortie des fichiers de journaux d'audit

/var/log/kubernetes/kubernetes.audit

--audit-log-maxage

Durée de rétention des fichiers de journaux archivés

7 jours

--audit-policy-file

Chemin vers le fichier de politique d'audit

/etc/kubernetes/audit-policy.yml

Étapes suivantes