Le leader mondial des télécommunications choisit AccuKnox pour la sécurité de l'exécution des conteneurs

Couverture d'exécution sur Kubernetes, CRI-O, containerd, Docker et Edge Infrastructure

Le client est un grand opérateur de commerce électronique qui s’est étendu aux opérations de réseaux mobiles et aux services cloud au cours de la dernière décennie. Son infrastructure s'étend sur :

• Kubernetes géré et auto-hébergé
• Une plateforme d'orchestration de conteneurs acquise séparément
• Conteneurs sur machines virtuelles
• Docker, conteneur, CRI-O, Podman
• Métal nu sur ARM et x86
• Nœuds périphériques colocalisés avec l'infrastructure radio

Un outil conçu pour gérer Kubernetes à lui seul couvrirait environ un tiers de ce domaine. L’exigence était un agent unique et un plan de contrôle avec un comportement cohérent sur tous les types d’exécution.

En savoir plus sur AccuKnox Plateforme de protection de la charge de travail dans le cloud (CWPP)

L’empreinte de déploiement qu’un agent devait couvrir. L’application, l’isolement et le suivi ont été notés séparément.

Portée de l'évaluation de la sécurité des conteneurs  

Le client a évalué la sécurité d’exécution dans trois domaines indépendants, chacun avec ses propres critères de réussite.

Déploiement isolé dans les locaux du client

Les agents ont été déployés sur le cluster sur site du client, couvrant les bases de données, les serveurs Web, les charges de travail internes des agents d'IA et les charges de travail générales des applications. La télémétrie de l'agent a été introduite dans un plan de contrôle AccuKnox hébergé dans le centre de données du client, qui gérait les rapports programmés et les alertes en temps réel à l'équipe de sécurité.

Spécifications du plan de contrôle : VM unique, 8 vCPU, 32 Go de RAM, volume de 256 Go. Installé à partir d'un bundle hors ligne signé. Aucune connectivité Internet à aucun moment pendant l'installation ou le fonctionnement.

Architecture POC. Agents dans le cluster du client, plan de contrôle dans le centre de données du client, rien ne quittant le périmètre.

Le processus impliquait une évaluation complète par rapport à 6 autres fournisseurs de sécurité des conteneurs.

Critères d'évaluation technique pour un PoC CWPP réussi – Une liste de contrôle

Chacun des 36 critères avait une condition de réussite écrite, définie et exécutée par le client.  

• L'écriture dans /bin ou /boot depuis l'intérieur d'un conteneur en cours d'exécution renvoie une autorisation refusée ; la tentative est enregistrée avec le contexte complet dans le plan de contrôle.
• La modification des magasins de certificats racine de confiance ou des bundles CA est bloquée au niveau de l'appel système.
• L'exécution depuis /tmp est bloquée ou signalée conformément à la politique.
• Les binaires de crypto-minage connus ne peuvent pas s'exécuter.
• Les scanners Docker, Crictl, Kubectl et réseau (Nmap, Masscan) ne peuvent pas s'exécuter depuis l'intérieur d'un conteneur.
• L'accès aux variables d'environnement est refusé par défaut (empêche les fuites secrètes via /proc).
• Le comportement de l'application est automatiquement basé ; les écarts sont signalés par des contrôles d'acceptation/suppression.
• Processus de confiance zéro allow-listing : seuls les binaires explicitement autorisés s'exécutent.
• L’activité du réseau est limitée aux processus identifiés comme fiables en fonction du comportement observé.

Zones notées supplémentaires : Analyse comparative CIS, MITRE ATT&CK cartographie des politiques et des violations, NIST 800-53 mappage de contrôle, détection de conteneur privilégié, utilisation PID/IPC de l'hôte, volumes hostPath inscriptibles, limites CPU/mémoire manquantes, charges de travail exposées en externe et comptes de service à accès anonyme.

Le Gestion des identités et des droits Kubernetes (KIEM) identification requise de :  

1. chaque utilisateur/service/espace de noms détenant ClusterAdmin,  
2. comptes de service surautorisés,  
3. rôles non liés à une charge de travail en direct, et  
4. sujets capables de créer des rôles ou des liens de rôles.  

Gestion des vulnérabilités requise numérisation d'images en cours d'exécution avec des résultats limités au cluster/espace de noms/charge de travail, plus un cycle de vie du triage (supprimer, accepter les risques, remédier)

Résultat de l'évaluation

30 des 36 critères ont été réussis proprement dès la première manche. Deux ont réussi partiellement. L’analyse des secrets dans les manifestes était prévue pour la deuxième phase.

Noté sur la carte de score du client, premier passage, aucune nouvelle tentative.

Découvrez comment les politiques d’exécution sont appliquées pour surveiller et bloquer les processus, les fichiers et les activités réseau non autorisés dans les charges de travail Kubernetes.

Les différenciateurs CWPP d'AccuKnox évalués par une grande entreprise mondiale

Application cohérente de l'exécution dans des environnements d'exécution mixtes L'environnement du client s'étendait au-delà de Kubernetes jusqu'à Docker, containerd, CRI-O, Podman, les machines virtuelles, le bare metal et l'infrastructure de pointe basée sur ARM. AccuKnox a appliqué les mêmes politiques d'exécution dans tous les environnements pris en charge à l'aide d'un seul agent au niveau du noyau, éliminant ainsi le besoin de modèles d'application spécifiques à l'exécution.
Application au niveau de l'appel système au lieu d'une réponse post-exécution L’évaluation a fait une distinction entre les plateformes qui mettent fin aux processus malveillants après leur exécution et celles qui empêchent les opérations non autorisées avant qu’elles ne se produisent. AccuKnox applique la politique au niveau de la couche d'appel système à l'aide d'eBPF et Modules de sécurité Linux (LSM), refuser les opérations non autorisées sur les fichiers, les processus et le réseau avant la fin de l'exécution.
Fonctionnement à air comprimé Le déploiement a été évalué dans un environnement entièrement isolé où ni les opérations d’installation ni les opérations d’exécution ne pouvaient s’appuyer sur la connectivité Internet. AccuKnox a été déployé à partir d'un bundle hors ligne signé, les agents et le plan de contrôle fonctionnant entièrement dans le périmètre réseau du client.
Génération de politiques comportementales pour l’application des moindres privilèges Maintenir manuellement les listes d’autorisation d’exécution sur des milliers de charges de travail n’était pas pratique. Au lieu de cela, AccuKnox a généré des politiques d'exécution spécifiques à la charge de travail en observant le comportement normal de l'application, permettant aux équipes de sécurité d'examiner et d'appliquer les politiques de moindre privilège sans création manuelle approfondie.
Identité Kubernetes et analyse graphique RBAC Au-delà de l’application de l’exécution, l’évaluation a évalué les risques d’identité de Kubernetes, notamment Administrateur de cluster affectations, comptes de service surautorisés, rôles RBAC inutilisés et chemins d'élévation de privilèges. Ces contrôles ont été traités comme des exigences de sécurité opérationnelle plutôt que comme des contrôles de conformité uniquement.

Réflexions finales

Les grandes entreprises s'attendent de plus en plus à une application de l'exécution qui empêche toute activité non autorisée avant son exécution, fonctionne de manière cohérente dans les environnements Kubernetes et non Kubernetes et peut être entièrement déployée dans une infrastructure isolée.

Cette évaluation a démontré que la protection d’exécution est finalement mesurée par une prévention réelle dans des conditions définies par le client. Dans 36 scénarios testés indépendamment, AccuKnox a fourni l'application, la portabilité et la flexibilité opérationnelle requises pour sécuriser l'un des environnements de conteneurs les plus complexes du secteur.

FAQ