Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Secure cluster operations with API server auditing

Dernière mise à jour :Sep 11, 2026

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é.

Important

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.

  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ê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.

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 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

Operations overview

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 interroger AliyunLogConfig , saisissez AliyunLogConfigs .

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.
  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 situé à côté 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 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 :

  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é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:nodes vers 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 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, 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

--audit-log-maxbackup

Nombre maximal de fichiers journaux tournants à conserver

10

--audit-log-maxsize

Taille maximale par fichier journal avant rotation

100 Mo

--audit-log-path

Chemin de sortie pour les fichiers journaux d'audit

/var/log/kubernetes/kubernetes.audit

--audit-log-maxage

Période de rétention des fichiers journaux tournants

7 jours

--audit-policy-file

Chemin vers le fichier de politique d'audit

/etc/kubernetes/audit-policy.yml

Étapes suivantes