Simplifiez la sécurité Kubernetes sur Amazon Web Services

L’intégration à Amazon Web Services Elastic Container Registry (ECR) est l’un de nos cas d’usage les plus populaires avec Snyk Container. Nous sommes donc ravis d’annoncer qu’il est désormais plus simple d’intégrer l’analyse des vulnérabilités de Snyk Container à vos services Amazon Elastic Kubernetes Service (EKS) et ECR.

À mesure que de nouvelles charges de travail sont déployées dans EKS, il est important de savoir d’où proviennent les conteneurs sous-jacents et s’ils sont sécurisés. Snyk Container détecte les charges de travail lors de leur création ou de leur modification dans EKS, puis se connecte à des registres comme ECR pour analyser les images de conteneur et détecter les vulnérabilités, et proposer des recommandations de correction. Dans le cadre de notre intégration à EKS, nous vous signalons également, à vous développeur, les problèmes de configuration potentiels de la charge de travail susceptibles de faciliter les attaques contre votre application.

Intégration d’AWS EKS et d’ECR

Détectez et sécurisez les charges de travail en cours d’exécution dans vos clusters EKS à l’aide des services AWS natifs

Le rythme d’évolution des applications modernes complique le suivi de toutes les charges de travail exécutées dans des clusters Kubernetes, d’autant plus qu’elles peuvent récupérer une nouvelle image de conteneur à chaque lancement. Snyk Container s’intègre à EKS et ECR pour détecter les charges de travail au lancement dans EKS, puis se connecte à ECR (ou à d’autres registres) afin de trouver l’image de conteneur source et de l’analyser à la recherche de vulnérabilités. Nous utilisons la propriété image du conteneur dans le pod pour localiser l’image source et établir la connexion. Pour EKS et ECR, nous utilisons AWS IAM pour authentifier la connexion.

Le contrôleur Kubernetes de Snyk vous offre une visibilité supplémentaire sur votre cluster Kubernetes, au-delà de l’analyse des vulnérabilités des images de conteneur. Nous pouvons également analyser la configuration de la charge de travail pour vous aider à hiérarchiser les corrections. Dans l’exemple ci-dessous, la configuration du déploiement ne définit aucune limite de processeur ou de mémoire, ne restreint ni l’exécution en tant que root ni l’écriture dans le système de fichiers racine, et ne supprime aucune fonctionnalité système, comme l’indique le badge « FAIL ». Si une charge de travail présente des vulnérabilités de gravité élevée et s’exécute avec une configuration non sécurisée, vous vous exposez à un risque accru : les attaquants disposent alors à la fois d’un point d’entrée et d’un potentiel élevé pour causer des dégâts.

Configuration des charges de travail Kubernetes.

Optimisez les images de conteneur grâce à des recommandations guidées

Snyk Container aide les développeurs à corriger rapidement les vulnérabilités en leur proposant des recommandations guidées pour mettre à niveau les images de base. Souvent, l’image de base est l’une des principales sources de vulnérabilités dans les conteneurs. Les images de base populaires sont conçues pour être très simples et vous permettre de démarrer rapidement un large éventail de projets. Elles peuvent donc inclure de nombreux outils et packages système superflus. La plupart des outils d’analyse de conteneurs fournissent une longue liste de vulnérabilités, sans indiquer aux développeurs dans quelle couche de l’image elles se trouvent ni recommander de mise à niveau de l’image de base.

Snyk dispose non seulement de l’une des bases de données de vulnérabilités les plus complètes pour les conteneurs et les dépendances open source, mais propose aussi, pour les conteneurs, des conseils afin de choisir des images de base moins vulnérables. Dans l’exemple ci-dessous, vous voyez l’image actuelle ainsi qu’une recommandation de mise à niveau mineure, qui entraîne un minimum de changements tout en réduisant le nombre de vulnérabilités. Nous proposons également des recommandations de mise à niveau majeure et des solutions alternatives, qui apportent des changements plus importants et peuvent nécessiter davantage de tests pour garantir la compatibilité avec votre application, mais qui peuvent aussi réduire considérablement le nombre de vulnérabilités.

Snyk et AWS : sécurité des conteneurs et sécurité open source tout au long du cycle de développement

La détection des charges de travail conteneurisées lors de leur lancement dans EKS n’est pas nécessairement la seule façon d’ajouter la détection des vulnérabilités aux pipelines applicatifs sur AWS. Snyk peut s’intégrer à des outils de CI comme AWS CodeBuild pour détecter les vulnérabilités des builds de conteneurs et des dépendances open source. Nous pouvons également nous intégrer directement à des registres comme ECR, Docker Hub et d’autres pour analyser les images que vous y avez déjà stockées.

Pour les développeurs, détecter les vulnérabilités plus tôt aide à maintenir le rythme de développement et de publication. Pour les équipes de sécurité, une détection précoce signifie moins de problèmes à « corriger virtuellement » ou à traiter au moyen de politiques d’exception en production. Avec Snyk, nous vous aidons à faire tout cela sans perturber votre workflow de développement habituel.

Pour commencer

Il est facile de démarrer avec Snyk et AWS. Vous pouvez créer un compte Snyk gratuit et commencer à analyser les conteneurs dans ECR et d’autres registres. Pour en savoir plus sur nos intégrations AWS pour Snyk Container, consultez notre documentation. Vous pouvez également analyser vos dépendances open source avec l’offre gratuite de Snyk.

Si vous participez à KubeCon EU cette année, venez nous voir ! Nous serons au stand S34.

Des membres de l’équipe Snyk participeront à trois sessions parallèles :

• Patrick Debois, directeur des relations DevOps, vous aidera à répondre à la question « Votre build/serveur est-il sécurisé ? » lors du Cloud Native Security Day, le 30 mars.

• Hayley Denbraver, Developer Relations, présentera ses recherches sur les vulnérabilités dans les charts Helm publics lors de la session « Territoires inexplorés : découvrir les vulnérabilités dans les charts Helm publics », le 1er avril.

• Nous avons également constitué un panel pour discuter de « Kubernetes et la sécurité cloud native : état des lieux » le 1er avril, avec les personnes suivantes :

  1. Gareth Rushgrove, chef de produit chez Snyk et ambassadeur CNCF

  2. Kirsten Newcomer, cheffe de produit principale chez Red Hat

  3. Scott Coulton, défenseur des développeurs cloud chez Microsoft, Docker Captain et ambassadeur CNCF

  4. Phil Estes, ingénieur émérite et directeur technique de la stratégie d’architecture des conteneurs chez IBM, président du conseil de supervision technique OCI

  5. Rags Srinivas, relations développeurs chez Snyk

Restez en sécurité !