La fonctionnalité d'audit des opérations KubeAPI vous permet de surveiller et d'auditer les opérations KubeAPI au sein de votre Service Mesh en enregistrant et en retraçant les activités des utilisateurs. Consultez les aperçus d'audit, les détails des opérations par compte et les listes d'opérations spécifiques aux ressources pour suivre les événements clés, analyser les statistiques et améliorer la sécurité et la traçabilité du maillage.
Prérequis
Informations générales
Dans cette rubrique, le terme « ressources » désigne les ressources Istio, notamment VirtualService, Gateway, DestinationRule, EnvoyFilter, Sidecar et ServiceEntry.
L'activation de l'audit du maillage entraîne la facturation des journaux d'audit générés. Pour plus d'informations sur la facturation, reportez-vous à la section Paiement par fonctionnalité.
Étape 1 : Activer l'audit des opérations KubeAPI
Nouvelles instances ASM
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez .
-
Sur la page Mesh Management, cliquez sur Create ASM Instance. Sélectionnez Enable Mesh Audit, configurez les autres paramètres, puis cliquez sur Create Service Mesh.
Pour plus d'informations sur les paramètres, consultez la section Créer une instance ASM.
RemarquePar défaut, ASM crée un Project nommé mesh-log-${Mesh-ID} pour les journaux d'audit, ainsi qu'un Logstore nommé audit-${Mesh-ID} au sein de ce Project pour stocker les journaux.
Instances ASM existantes
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez .
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez .
Sur la page Mesh Audit, sélectionnez Enable Mesh Audit, puis cliquez sur OK.
Étape 2 : Consulter les rapports d'audit KubeAPI
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez .
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez .
-
Sur la page Mesh Audit, cliquez sur l'onglet API Access Overview ou Operation Details pour afficher les détails du rapport.
-
API Access Overview : Consultez des informations détaillées sur le comportement d'accès KubeAPI de l'instance de maillage.
La page API Access Overview comprend le diagramme circulaire Access source distribution, le panneau Unauthorized access attempts et le tableau Public network access list. La liste d'accès au réseau public inclut des colonnes telles que Source IP address, Access count, Failure rate %, Unauthorized access attempts, High-risk IP, Country, Province, City et ISP.
-
Operation Details : Affichez une liste détaillée des opérations pour une ressource spécifiée dans l'instance de maillage.
Sélectionnez ou saisissez un type de ressource pour effectuer une requête en temps réel. Visualisez le nombre total de différents événements, la répartition par namespace, les tendances chronologiques et une liste détaillée des opérations. Le haut de l'onglet Resource operations propose des filtres tels que Resource type, Namespace et Status code. La zone d'aperçu affiche le nombre d'opérateurs, de namespaces, de méthodes d'opération et le taux de réussite. Sous cette zone, vous trouverez des panneaux tels que la chronologie Operation trace, Create event namespace distribution, Update event namespace distribution, Access event namespace distribution et Delete event namespace distribution.
-
Opérations connexes
Enregistrements de journaux détaillés
Pour exécuter des requêtes personnalisées et analyser les journaux d'audit, accédez à la console Simple Log Service afin de consulter les enregistrements de journaux détaillés.
Connectez-vous à la console Simple Log Service.
Dans la section Projects, cliquez sur le Project nommé mesh-log-${Mesh-ID}.
-
Sélectionnez le Logstore nommé audit-${Mesh-ID} et cliquez sur Search & Analyze pour afficher les journaux d'audit correspondants.
RemarqueLorsque vous activez l'audit du maillage, un Logstore nommé audit-${Mesh-ID} est automatiquement ajouté au Project généré.
Le Logstore destiné aux journaux d'audit dispose d'un index configuré par défaut. Ne modifiez pas cet index, sous peine de compromettre le bon fonctionnement des rapports.
Par défaut, Simple Log Service conserve les journaux d'audit API Server provenant d'ASM pendant 30 jours. Pour modifier la période de conservation par défaut, consultez la section Gérer un Logstore.
Voici les méthodes courantes pour rechercher des journaux d'audit :
Pour interroger les opérations effectuées par un utilisateur RAM spécifique, saisissez l'ID de l'utilisateur RAM dans la zone de recherche et cliquez sur Search & Analyze.
Pour interroger les opérations sur une ressource spécifique, saisissez le nom de la ressource dans la zone de recherche et cliquez sur Search & Analyze.
Pour filtrer les opérations effectuées par les composants système, saisissez
NOT user.username: node NOT user.username: serviceaccount NOT user.username: apiserver NOT user.username: kube-scheduler NOT user.username: kube-controller-managerdans la zone de recherche et cliquez sur Search & Analyze.
Pour plus d'informations sur les méthodes de requête et d'analyse, consultez la section Aperçu des requêtes.
Pour recevoir des alertes en temps réel concernant les opérations sur des ressources spécifiques, utilisez la fonctionnalité d'alerte de Simple Log Service. Les canaux de notification pris en charge incluent les SMS, les robots de discussion DingTalk, les e-mails, les webhooks personnalisés et Notification Center. Pour plus d'informations, consultez la section Alertes.
Vous pouvez également utiliser les instructions de requête issues des rapports d'audit pour interroger les journaux d'audit :
-
Exemple 1 : Alerte sur l'exécution de commandes dans un conteneur
Une entreprise impose des restrictions strictes sur l'utilisation de son instance de maillage et n'autorise pas les utilisateurs à se connecter aux conteneurs ni à y exécuter des commandes. Si un utilisateur exécute une commande, une alerte doit être déclenchée immédiatement. L'alerte doit inclure des détails tels que le conteneur concerné, la commande exécutée, l'opérateur, l'ID de l'événement, l'heure et l'adresse IP source.
-
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 "event_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 "operator", CASE WHEN json_array_length(sourceIPs) = 1 THEN json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END as "source_ip" LIMIT 100 -
Expression conditionnelle :
operation_event =~ ".*"
-
-
Exemple 2 : Alerte sur les échecs d'accès public
Une instance de maillage a l'accès public activé. Pour prévenir les attaques malveillantes, vous devez surveiller le nombre de tentatives d'accès public et le taux d'échec. Si le nombre de tentatives d'accès depuis une adresse IP atteint un seuil (par exemple, 10) et que le taux d'échec dépasse un seuil (par exemple, 50 %), une alerte doit être déclenchée immédiatement. L'alerte doit inclure la région géographique de l'adresse IP de l'utilisateur, l'adresse IP source et indiquer s'il s'agit d'une adresse IP à haut risque.
-
Instruction de requête :
* | SELECT ip AS "source_ip", total AS "request_count", round(rate * 100, 2) AS "failure_rate_pct", failCount AS "forbidden_count", CASE WHEN security_check_ip(ip) = 1 THEN 'yes' ELSE 'no' END AS "is_high_risk_ip", 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' HAVING "request_count" > 10 AND "failure_rate_pct" > 50 ORDER BY "request_count" DESC LIMIT 100 -
Expression conditionnelle :
source_ip =~ ".*"
-
Si vous supprimez accidentellement le Project SLS dédié à l'audit du maillage, vous devez le recréer pour continuer à utiliser la fonctionnalité.
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez .
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez .
-
Sur la page Mesh Audit, dans la boîte de dialogue Rebuild Mesh Audit, cliquez sur Recreate.
Le nom du Project recréé est identique au nom du Project précédent, avec un horodatage ajouté.
Documents connexes
Pour envoyer des notifications d'alerte rapides aux contacts lorsque des ressources importantes changent, consultez la section Configurer des alertes d'audit pour les opérations sur les ressources du maillage.
Vous pouvez configurer l'identité de charge de travail, l'authentification mutuelle, l'authentification des requêtes et les politiques d'autorisation dans le maillage afin de gérer les ressources du maillage avec plus de granularité et d'améliorer la sécurité du maillage. Pour plus d'informations, consultez la section Présentation de la sécurité zero trust.