Concevoir une architecture de sécurité Zero Trust pour les applications Kubernetes avec NGINX

NGINX | 26 septembre 2022

La sophistication et le nombre des cyberattaques augmentent de manière exponentielle, ce qui expose considérablement vos applications déployées dans des environnements Kubernetes sur site, hybrides et multiclouds. Les modèles de sécurité traditionnels reposent sur une approche périmétrique et partent du principe que les utilisateurs sont dignes de confiance (et que leurs communications sont sécurisées) s’ils se trouvent à l’intérieur des limites sécurisées de l’environnement. Dans les environnements distribués actuels, le concept de zone sûre à l’intérieur du périmètre n’existe plus : les communications provenant de l’« intérieur » de l’environnement peuvent être tout aussi dangereuses que les menaces externes.

Dans cet article de blog, nous examinons les avantages de l’adoption d’un modèle Zero Trust pour sécuriser votre infrastructure Kubernetes, ainsi que la manière dont NGINX peut vous aider à renforcer votre posture de sécurité.

Qu’est-ce que le modèle Zero Trust ?

Zero Trust est un modèle de sécurité fondé sur l’identité plutôt que sur la localisation. Il part du principe que toute demande d’accès aux applications, aux données et aux appareils peut constituer une attaque, que le demandeur semble se trouver sur site, à distance ou dans le cloud.

Pour mettre en œuvre les trois principes fondamentaux du modèle Zero Trust – ne jamais faire confiance, toujours vérifier et surveiller en continu –, chaque utilisateur, service, application et appareil doit continuellement fournir une preuve d’authentification et d’autorisation. Des privilèges à durée limitée sont accordés selon des politiques d’accès dynamiques et conformément au principe du moindre privilège.

Toutes les communications sont chiffrées et acheminées via un point de décision et d’application des politiques (PDP/PEP), qui authentifie toutes les parties et leur accorde des privilèges en fonction de politiques d’accès dynamiques. En outre, des fonctionnalités d’audit, de surveillance, de création de rapports et d’automatisation sont mises en place afin d’analyser, d’évaluer et d’atténuer les risques de sécurité.

Schéma de l’architecture Zero Trust

Comment le modèle Zero Trust renforce votre posture de sécurité

Le modèle Zero Trust améliore votre posture de sécurité de plusieurs façons :

  • Bloque automatiquement les activités non autorisées
  • Applique des contrôles d’accès afin de réduire la surface d’attaque exposée
  • Détecte les anomalies comportementales et les indicateurs de compromission
  • Définit en temps réel des politiques de moindre privilège qui limitent la durée d’accès
  • Authentifie et valide en permanence l’identité afin de bloquer les attaques en cours

Le modèle Zero Trust est particulièrement essentiel pour les applications modernes cloud-native exécutées dans un environnement Kubernetes. Faiblement couplés et portables, les applications et services distribués sont conteneurisés et s’exécutent dans des environnements hybrides et multicloud, où une sécurité fondée sur la localisation n’est pas envisageable. La sécurité repose nécessairement sur la validation continue des identités et des privilèges, le chiffrement de bout en bout et la surveillance.

Comment mettre en œuvre une sécurité Zero Trust

Pour respecter les principes du modèle Zero Trust, votre environnement Kubernetes doit fournir des fonctionnalités de sécurité essentielles, telles que l’authentification, l’autorisation, le contrôle des accès, les politiques de sécurité, le chiffrement, la surveillance et l’audit des utilisateurs, des applications et des services.

Une solution possible consiste à intégrer la sécurité directement dans l’application. Toutefois, cela signifie que vos développeurs doivent mettre en œuvre de nombreuses procédures de sécurité : établir et vérifier la confiance, gérer les identités des utilisateurs et les certificats, chiffrer et déchiffrer toutes les communications, etc. Ils doivent également comprendre et intégrer des technologies tierces telles que TLS et l’authentification unique (SSO). Tout cela ne fait pas qu’ajouter de la complexité à votre déploiement Kubernetes, qui l’est déjà suffisamment. Cela détourne les développeurs de ce sur quoi ils doivent (et veulent !) se concentrer : l’optimisation des fonctionnalités métier de l’application.

Pas de panique : il existe une meilleure solution. Confiez la sécurité et les autres exigences non fonctionnelles à votre infrastructure Kubernetes ! Les outils de connectivité pour les clusters Kubernetes, tels que les contrôleurs Ingress et les maillages de services, peuvent fournir des PDP et des PEP pour toutes les communications entre vos applications et services, qu’elles proviennent d’utilisateurs, d’autres applications ou d’autres services. Vous pouvez ainsi vous concentrer sur votre expertise métier et les fonctionnalités essentielles, tout en livrant vos applications plus rapidement et plus facilement.

Comment F5 NGINX peut vous aider

Comme l’illustre le schéma suivant, la solution NGINX pour une connectivité Kubernetes sécurisée comprend tous les composants et outils indépendants de l’infrastructure dont vous avez besoin pour protéger efficacement et de bout en bout vos utilisateurs, applications distribuées, microservices et API à grande échelle, quel que soit l’environnement : sur site, hybride ou multicloud. S’appuyant sur le plan de données le plus populaire au monde, cette solution associe :

  • NGINX Ingress Controller en tant que contrôleur Ingress pour Kubernetes et PDP/PEP s’intégrant à des fournisseurs tiers d’identité et d’authentification unique (SSO). Basé sur NGINX Plus, NGINX Ingress Controller assure des fonctions avancées de connectivité, de surveillance et de visibilité, d’authentification et d’authentification unique (SSO), et fait office de passerelle API.
  • NGINX Service Mesh est un maillage de services léger, clé en main et convivial pour les développeurs, qui sécurise la connectivité des services au sein du cluster Kubernetes. Le side-car de niveau entreprise, qui fait office de PDP/PEP et est colocalisé avec chaque service Kubernetes, repose sur NGINX Plus.
  • NGINX App Protect pour une protection complète des applications modernes et des API, reposant sur les technologies de sécurité de pointe de F5. Cette solution adopte une approche modulaire afin d’offrir une grande flexibilité dans les scénarios de déploiement et une utilisation optimale des ressources :
    • NGINX App Protect WAF – Un WAF robuste et léger qui protège contre le Top 10 de l’OWASP et assure la conformité à la norme PCI DDS
    • NGINX App Protect DoS – Détection et atténuation comportementales des attaques DoS, avec une protection cohérente et adaptative sur l’ensemble des clouds et des architectures

schéma Zero Trust 2

La solution NGINX vous permet de :

  • Intégrez des contrôles de sécurité robustes dans des environnements distribués sans ralentir le rythme des mises en production ni nuire aux performances
  • Bloquez automatiquement les attaques en cours grâce à une authentification continue, à la validation des identités et à la détection des anomalies comportementales
  • Mettez en œuvre en temps réel des politiques de moindre privilège, un contrôle d’accès granulaire, un chiffrement de bout en bout et une gouvernance couvrant plusieurs équipes
  • Livrez des applications en toute sécurité, du code jusqu’au client, grâce à un WAF intégré et robuste et à une protection contre les attaques DoS au niveau applicatif
  • Évaluez et améliorez en continu la posture de sécurité de votre environnement Kubernetes grâce à des métriques granulaires en temps réel et historiques
  • Simplifiez le déploiement et la gestion des communications sécurisées entre utilisateurs et services, ainsi qu’entre services, grâce à la consolidation des technologies

Mettez en œuvre une sécurité Zero Trust complète avec NGINX

À mesure que les organisations se développent, il devient essentiel de décharger la couche applicative des exigences qui ne sont pas propres aux fonctionnalités d’une application, telles que les fonctions de sécurité Zero Trust. Comme expliqué précédemment, cela évite aux développeurs d’avoir à créer, maintenir et reproduire la logique de sécurité dans l’ensemble de leurs applications. Ils peuvent ainsi exploiter facilement les technologies de sécurité au niveau de la plateforme. NGINX permet d’appliquer de manière centralisée les politiques de sécurité pour Kubernetes, à la périphérie du cluster avec NGINX Ingress Controller et au sein du cluster avec NGINX Service Mesh. Vous pouvez renforcer la protection des applications contre les cyberattaques sophistiquées grâce aux solutions WAF et DoS de NGINX App Protect, déployées à la périphérie ou au sein du cluster selon les exigences de sécurité de vos applications.

Examinons en détail comment la solution NGINX intègre les fonctionnalités dont vous avez besoin pour mettre en œuvre une sécurité Zero Trust complète pour vos déploiements Kubernetes.

Authentification et autorisation

L’un des principes fondamentaux de la sécurité Zero Trust est que chaque appareil, utilisateur, service et requête doit être authentifié et autorisé. L’authentification consiste à vérifier l’identité, autrement dit à s’assurer que chaque partie prenant part à une communication est bien celle qu’elle prétend être. L’autorisation consiste à vérifier qu’une partie dispose des droits nécessaires pour accéder à la ressource ou à la fonction demandée.

Pour appliquer ce principe, la solution NGINX propose plusieurs options permettant de mettre en œuvre l’authentification et l’autorisation, notamment l’authentification HTTP Basic, les jetons web JSON (JWT) et OpenID Connect grâce à des intégrations avec des fournisseurs d’identité tels qu’Okta et Azure Active Directory (AD). La solution NGINX attribue également des identités sécurisées aux services (de la même manière que les utilisateurs d’applications reçoivent une identification sous forme de certificats), ce qui permet de les authentifier et de les autoriser à effectuer des actions dans l’ensemble du cluster Kubernetes. Outre la gestion des identités des charges de travail, la solution NGINX automatise la gestion des certificats grâce à des intégrations natives avec les infrastructures à clés publiques (PKI) et les autorités de certification.

Étant donné que NGINX Ingress Controller examine déjà toutes les requêtes entrant dans le cluster et les achemine vers les services appropriés, il constitue l’emplacement le plus efficace pour centraliser l’authentification et l’autorisation des utilisateurs, ainsi que, dans certains cas, l’authentification des services.

Pour en savoir plus, consultez l’article « Mise en œuvre de l’authentification OpenID Connect pour Kubernetes avec Okta et NGINX Ingress Controller » sur notre blog.

Chiffrement et intégrité des données

Un autre principe du modèle Zero Trust veut que toutes les communications soient sécurisées — leur confidentialité et leur intégrité devant être préservées — quel que soit l’emplacement des participants. Les données ne doivent pas pouvoir être lues par des parties non autorisées ni modifiées pendant leur transmission. Pour respecter ce principe, la solution NGINX utilise le chiffrement SSL/TLS pour les communications entre les utilisateurs et les services, ainsi que l’authentification et le chiffrement TLS mutuel (mTLS) pour les communications entre les services.

Si l’architecture de votre application n’implique pas de communication de service à service au sein du cluster Kubernetes, NGINX Ingress Controller peut suffire à répondre à vos besoins en matière d’intégrité des données. Deux options principales s’offrent à vous :

  • Avec le TLS Passthrough, NGINX Ingress Controller achemine directement les connexions chiffrées par SSL/TLS vers le service, sans les déchiffrer ni nécessiter l’accès aux certificats ou aux clés SSL/TLS.
  • Avec la terminaison SSL/TLS, NGINX Ingress Controller agit comme un proxy inverse en mettant fin à la connexion TLS avec le demandeur, puis en utilisant le protocole mTLS ou le protocole SSL/TLS côté service pour chiffrer une nouvelle connexion à vos services Kubernetes (serveurs backend et en amont).

Si votre architecture implique des communications de service à service au sein du cluster, vous avez besoin à la fois de NGINX Ingress Controller et de NGINX Service Mesh pour garantir l’intégrité des données. NGINX Service Mesh veille à ce que seuls certains services soient autorisés à communiquer entre eux et utilise le protocole mTLS pour les authentifier et chiffrer leurs communications. Avec NGINX Service Mesh, vous pouvez mettre en œuvre le protocole mTLS de manière entièrement transparente, ce qui signifie que les développeurs n’ont pas besoin d’adapter leurs applications pour y intégrer des certificats, ni même de savoir qu’une authentification mutuelle a lieu.

Pour en savoir plus sur la sécurisation des communications dans un cluster Kubernetes, consultez l’article « L’architecture mTLS dans NGINX Service Mesh » sur notre blog.

Contrôle d’accès et politique d’accès

Le contrôle d’accès est un autre élément essentiel du modèle Zero Trust. Kubernetes utilise le contrôle d’accès basé sur les rôles (RBAC) pour déterminer les ressources et les opérations auxquelles les différents utilisateurs peuvent accéder. Il définit la manière dont les utilisateurs, ou les groupes d’utilisateurs, peuvent interagir avec les objets ou les espaces de noms Kubernetes du cluster.

La solution de connectivité Kubernetes de NGINX prend en charge le contrôle d’accès basé sur les rôles (RBAC), ce qui facilite son alignement sur les politiques de sécurité de votre organisation. Grâce au RBAC, les utilisateurs bénéficient d’un accès contrôlé aux fonctionnalités dont ils ont besoin pour accomplir leur travail, sans avoir à soumettre un ticket au service informatique et à attendre son traitement. Sans RBAC, les utilisateurs peuvent obtenir des autorisations dont ils n’ont pas besoin ou auxquelles ils n’ont pas droit, ce qui peut créer des vulnérabilités en cas d’utilisation abusive.

Lorsque vous configurez le contrôle d’accès basé sur les rôles (RBAC) avec NGINX Ingress Controller, vous pouvez gérer l’accès de nombreux utilisateurs et de nombreuses équipes en adaptant les autorisations aux différents rôles de l’environnement de développement et de livraison d’applications de votre organisation. Son outil de gestion granulaire des accès permet à plusieurs équipes de bénéficier d’un accès en libre-service tout en assurant la gouvernance.

Pour découvrir comment tirer parti du contrôle d’accès basé sur les rôles (RBAC) avec NGINX Ingress Controller, regardez notre webinaire sur DevNetwork, « Déploiements Kubernetes avancés avec NGINX Ingress Controller ». À partir de 13 min 50 s, nos experts expliquent comment exploiter le RBAC et l’allocation des ressources pour renforcer la sécurité, permettre le libre-service et assurer la mutualisation.

Observabilité

L’audit, la surveillance, la journalisation, le traçage et la création de rapports sont des éléments essentiels dans un environnement Zero Trust. Plus vous pouvez recueillir d’informations sur l’état de l’infrastructure de vos applications Kubernetes et les corréler, les analyser et les évaluer efficacement, plus vous pouvez renforcer votre posture de sécurité.

Vous utilisez probablement déjà des outils de supervision dans votre déploiement Kubernetes et n’avez pas besoin d’un outil supplémentaire. Pour vous donner une vue d’ensemble de ce qui se passe au sein de vos clusters, nous avons instrumenté l’API NGINX Plus afin de faciliter l’exportation des métriques vers tout outil tiers acceptant le format JSON, et proposons des intégrations prêtes à l’emploi avec des outils populaires tels que OpenTelemetry et Grafana et Prometheus. Vous bénéficiez d’informations ciblées sur la connectivité des applications grâce à des traces détaillées qui vous permettent de comprendre comment les requêtes sont traitées de bout en bout : NGINX Ingress Controller fournit des informations sur la connectivité entre votre cluster et les clients externes, tandis que NGINX Service Mesh couvre la connectivité entre les applications et services conteneurisés basés sur des microservices au sein du cluster.

Protection WAF et contre les attaques DoS

Avec NGINX App Protect, vous pouvez renforcer davantage la sécurité de vos applications distribuées en les protégeant contre des menaces telles que celles du Top 10 de l’OWASP et les attaques par déni de service (DoS) de couche 7. Partie intégrante de la solution de connectivité sécurisée de bout en bout de NGINX, NGINX App Protect offre une sécurité agile et centrée sur les applications contre les menaces les plus avancées, bien au-delà des signatures de base. Il s’appuie sur l’expertise reconnue et éprouvée de F5 en matière de sécurité, sans compromettre la rapidité des mises en production ni les performances. Il peut facilement transmettre les données de télémétrie de sécurité à des solutions tierces d’analyse et de visibilité, et réduit les faux positifs grâce à des signatures à haut niveau de confiance et à l’analyse automatisée des comportements.

La conception modulaire de NGINX App Protect vous permet de déployer la protection WAF, la protection contre les attaques DoS ou les deux, sur une même instance ou sur des instances distinctes, selon vos besoins. Par exemple, vous pouvez choisir de les déployer avec NGINX Ingress Controller à la périphérie de votre cluster, une solution idéale pour assurer une protection granulaire et cohérente à l’échelle de l’ensemble du cluster. Si vous avez plutôt besoin de stratégies propres à plusieurs applications au sein d’un cluster, vous pouvez déployer la protection WAF et/ou la protection contre les attaques DoS au niveau du service ou du pod.

Pour en savoir plus sur le déploiement des protections WAF et DoS, consultez l’article « Décaler les outils de sécurité vers l’amont pour des applications plus sûres » sur notre blog.

Démarrez avec la solution de sécurité Zero Trust de NGINX pour Kubernetes

Que vous débutiez avec Kubernetes ou que vous soyez un utilisateur expérimenté l’exploitant en production depuis un certain temps, NGINX propose un ensemble complet d’outils et de composants pour répondre à vos besoins et renforcer votre niveau de sécurité.

Commencez par demander votre essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS, et téléchargez NGINX Service Mesh, toujours gratuit.


Partager

À propos de l’auteur

Ilya Krutov
Ilya KrutovResponsable senior du marketing produit | F5 NGINX

Autres articles de Ilya Krutov

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
NGINX | 13/10/2025

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA

Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
NGINX | 03/11/2023

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?

Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
NGINX | 11/03/2020

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX

Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
NGINX | 11/06/2019

Un testeur d’expressions régulières pour NGINX et NGINX Plus

Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.

Caches partagés avec les clusters de cache NGINX Plus, partie 1
NGINX | 24/01/2017

Caches partagés avec les clusters de cache NGINX Plus, partie 1

Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.

Introduction aux microservices
NGINX | 19/05/2015

Introduction aux microservices

Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.