Six façons de sécuriser Kubernetes à l'aide d'outils de gestion du trafic

Rédacteur – Ce billet fait partie d’ une série en 10 parties :

1. Réduisez la complexité avec Kubernetes de niveau production
2. Comment améliorer la résilience dans Kubernetes grâce à la gestion avancée du trafic
3. Comment améliorer la visibilité dans Kubernetes
4. Six façons de sécuriser Kubernetes à l'aide d'outils de gestion du trafic (cet article)
5. Guide pour choisir un contrôleur d'entrée, partie 1 : Identifiez vos besoins
6. Guide pour choisir un contrôleur d'entrée, partie 2 : Risques et pérennité
7. Guide pour choisir un contrôleur d'entrée, partie 3 : Open Source contre Par défaut vs. Commercial
8. Guide pour choisir un contrôleur d'entrée, partie 4 : Options du contrôleur d'entrée NGINX
9. Comment choisir un maillage de services
10. Test des performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’ensemble complet des blogs sous forme d’eBook gratuit – Taking Kubernetes from Test to Production .

Comme indiqué dans Sécuriser les applications cloud natives sans perdre en vitesse , nous avons observé trois facteurs qui rendent les applications cloud natives plus difficiles à sécuriser que les applications traditionnelles :

1. La diffusion d’applications natives dans le cloud entraîne une prolifération d’outils et offre des services de qualité professionnelle incohérents
2. Les coûts de livraison d’applications cloud natives peuvent être imprévisibles et élevés
3. Les équipes SecOps ont du mal à protéger les applications cloud natives et sont en désaccord avec DevOps

Bien que ces trois facteurs puissent avoir un impact égal sur la sécurité, le troisième facteur peut être le problème le plus difficile à résoudre, peut-être parce qu’il est le plus « humain ». Lorsque SecOps n’est pas en mesure ou habilité à protéger les applications cloud natives, certaines conséquences sont évidentes (vulnérabilités et violations), mais d’autres sont cachées, notamment une agilité ralentie et une transformation numérique bloquée.

Examinons de plus près ces coûts cachés. Les organisations choisissent Kubernetes pour sa promesse d’agilité et d’économies de coûts. Mais lorsqu’il y a des incidents de sécurité dans un environnement Kubernetes, la plupart des organisations retirent leurs déploiements Kubernetes de la production . Cela ralentit les initiatives de transformation numérique qui sont essentielles pour l’avenir de l’organisation – sans parler des efforts d’ingénierie et de l’argent gaspillés. La conclusion logique est la suivante : si vous souhaitez faire passer Kubernetes du test à la production, la sécurité doit être considérée comme un composant stratégique appartenant à tous les membres de l’organisation.

Dans cet article, nous abordons six cas d’utilisation de sécurité que vous pouvez résoudre avec les outils de gestion du trafic Kubernetes, permettant à SecOps de collaborer avec DevOps et NetOps pour mieux protéger vos applications et API cloud natives. Une combinaison de ces techniques est souvent utilisée pour créer une stratégie de sécurité complète conçue pour assurer la sécurité des applications et des API tout en minimisant l’impact sur les clients.

1. Résoudre rapidement les CVE pour éviter les cyberattaques
2. Arrêtez les attaques OWASP Top 10 et les attaques par déni de service
3. Déchargez l'authentification et l'autorisation des applications
4. Mettre en place un libre-service avec des garde-fous
5. Mettre en œuvre le cryptage de bout en bout
6. Assurez-vous que les clients utilisent un chiffrement fort avec une implémentation fiable

Terminologie de la sécurité et de l'identité

Avant de passer aux cas d’utilisation, voici un bref aperçu de certains termes de sécurité et d’identité que vous rencontrerez tout au long de cet article.

• Authentification et autorisation – Fonctions requises pour garantir que seuls les « bons » utilisateurs et services peuvent accéder aux backends ou aux composants d’application :

  • Authentification – Vérification de l’identité pour garantir que les clients qui font des demandes sont bien ceux qu’ils prétendent être. Réalisé via des jetons d'identification, tels que des mots de passe ou des jetons Web JSON (JWT).

  • Autorisation – Vérification de l’autorisation d’accéder à une ressource ou à une fonction. Réalisé via des jetons d'accès, tels que les attributs de couche 7 comme les cookies de session, les identifiants de session, les identifiants de groupe ou le contenu des jetons.

• Vulnérabilités et expositions critiques (CVE) – Une base de données de failles divulguées publiquement « dans un logiciel, un micrologiciel, un matériel ou un composant de service résultant d'une faiblesse qui peut être exploitée, provoquant un impact négatif sur la confidentialité, l'intégrité ou la disponibilité d'un ou de plusieurs composants impactés » ( https://www.cve.org/ ). Les CVE peuvent être découverts par les développeurs qui gèrent l'outil, un testeur de pénétration, un utilisateur ou un client, ou une personne de la communauté (comme un « chasseur de bugs »). Il est courant de donner au propriétaire du logiciel le temps de développer un correctif avant que la vulnérabilité ne soit divulguée publiquement, afin de ne pas donner un avantage aux mauvais acteurs.

• Attaque par déni de service (DoS) – Une attaque dans laquelle un acteur malveillant inonde un site Web de requêtes (TCP/UDP ou HTTP/HTTPS) dans le but de faire planter le site. Étant donné que les attaques DoS ont un impact sur la disponibilité, leur principal résultat est de nuire à la réputation de la cible. Une attaque par déni de service distribué (DDoS) , dans laquelle plusieurs sources ciblent le même réseau ou service, est plus difficile à combattre en raison du réseau potentiellement vaste d'attaquants. La protection DoS nécessite un outil qui identifie et prévient les attaques de manière adaptative. En savoir plus sur Qu’est-ce que le déni de service distribué (DDoS) ?

• Chiffrement de bout en bout (E2EE) – Pratique consistant à crypter entièrement les données lorsqu’elles passent de l’utilisateur à l’application et vice versa. E2EE nécessite des certificats SSL et potentiellement mTLS.

• TLS mutuel (mTLS) – Pratique consistant à exiger une authentification (via un certificat SSL/TLS) pour le client et l’hôte. L'utilisation de mTLS protège également la confidentialité et l'intégrité des données transmises entre le client et l'hôte. mTLS peut être réalisé jusqu'au niveau du pod Kubernetes, entre deux services du même cluster. Pour une excellente introduction à SSL/TLS et mTLS, voir Qu'est-ce que mTLS ? sur F5 Labs.

• Authentification unique (SSO) – Les technologies SSO (notamment SAML, OAuth et OIDC) facilitent la gestion de l’authentification et de l’autorisation.

  • Authentification simplifiée – L’authentification unique élimine le besoin pour un utilisateur de disposer d’un jeton d’identification unique pour chaque ressource ou fonction différente.

  • Autorisation standardisée – SSO facilite la définition des droits d’accès des utilisateurs en fonction du rôle, du service et du niveau d’ancienneté, éliminant ainsi le besoin de configurer les autorisations pour chaque utilisateur individuellement.

• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – Un protocole permettant d’établir des liens authentifiés et cryptés entre des ordinateurs en réseau. Les certificats SSL/TLS authentifient l'identité d'un site Web et établissent une connexion cryptée. Bien que le protocole SSL ait été abandonné en 1999 et remplacé par le protocole TLS, il est encore courant de désigner ces technologies associées par « SSL » ou « SSL/TLS » ; par souci de cohérence, nous utiliserons SSL/TLS pour le reste de cet article.

• Pare-feu d'application Web (WAF) – Un proxy inverse qui détecte et bloque les attaques sophistiquées contre les applications et les API (y compris OWASP Top 10 et d'autres menaces avancées) tout en laissant passer le trafic « sûr ». Les WAF protègent contre les attaques qui tentent de nuire à la cible en volant des données sensibles ou en détournant le système. Certains fournisseurs consolident la protection WAF et DoS dans le même outil, tandis que d'autres proposent des outils WAF et DoS distincts.

• Zero Trust – Un concept de sécurité fréquemment utilisé dans les organisations à haut niveau de sécurité, mais qui concerne tout le monde, dans lequel les données doivent être sécurisées à toutes les étapes du stockage et du transport. Cela signifie que l’organisation a décidé de ne « faire confiance » à aucun utilisateur ou appareil par défaut, mais d’exiger plutôt que tout le trafic soit soigneusement contrôlé. Une architecture Zero Trust comprend généralement une combinaison d’authentification, d’autorisation et de mTLS avec une forte probabilité que l’organisation implémente E2EE.

Cas d'utilisation : Résoudre rapidement les CVE pour éviter les cyberattaques

Solution: Utilisez des outils avec des notifications de correctifs opportunes et proactives

Selon une étude du Ponemon Institute , en 2019, il y avait une « période de grâce » moyenne de 43 jours entre la publication d’un correctif pour une vulnérabilité critique ou hautement prioritaire et le moment où les organisations étaient confrontées à des attaques tentant d’exploiter la vulnérabilité. Chez F5 NGINX, nous avons constaté que cette fenêtre se rétrécissait considérablement au cours des années suivantes (même jusqu'au jour zéro dans le cas d'Apple iOS 15 en 2021 ), c'est pourquoi nous recommandons d'appliquer les correctifs dès que possible. Mais que se passe-t-il si les correctifs pour vos outils de gestion du trafic ne sont pas disponibles pendant des semaines, voire des mois, après l’annonce d’un CVE ?

Les outils développés et maintenus par les contributeurs de la communauté (plutôt que par une équipe d'ingénieurs dédiée) ont le potentiel d'être en retard de plusieurs semaines ou de plusieurs mois par rapport aux annonces CVE, ce qui rend peu probable que les organisations puissent appliquer les correctifs dans cette fenêtre de 43 jours . Dans un cas , il a fallu quatre mois à OpenResty pour appliquer un correctif de sécurité lié à NGINX. Cela a laissé toute personne utilisant un contrôleur Ingress basé sur OpenResty vulnérable pendant au moins quatre mois, mais en réalité, il y a généralement un délai supplémentaire avant que les correctifs ne soient disponibles pour les logiciels qui dépendent d'un projet open source.

Pour obtenir la mise à jour corrective CVE la plus rapide, recherchez deux caractéristiques lors de la sélection des outils de gestion du trafic :

• Une équipe d'ingénieurs dédiée – Lorsque le développement d'outils est géré par une équipe d'ingénieurs plutôt que par des bénévoles de la communauté, vous savez qu'il existe un groupe de personnes dédiées à la santé de l'outil et qui peuvent prioriser la publication d'un correctif dès que possible.
• Une base de code intégrée – Sans aucune dépendance externe (comme nous en avons discuté avec OpenResty), les correctifs ne sont qu’à un sprint agile.

Pour en savoir plus sur les correctifs CVE, lisez Atténuer les vulnérabilités de sécurité rapidement et facilement avec NGINX Plus .

Cas d'utilisation : Arrêtez les attaques OWASP Top 10 et DoS

Solution: Déployez une protection WAF et DoS flexible et compatible avec Kubernetes

Le choix de la bonne protection WAF et DoS pour les applications Kubernetes dépend de deux facteurs (en plus des fonctionnalités) :

• Flexibilité – Il existe des scénarios dans lesquels il est préférable de déployer des outils dans Kubernetes. Vous avez donc besoin d'outils indépendants de l'infrastructure qui peuvent s'exécuter dans ou en dehors de Kubernetes. L'utilisation du même outil pour tous vos déploiements vous permet de réutiliser les politiques et de réduire la courbe d'apprentissage de vos équipes SecOps.
• Empreinte – Les meilleurs outils Kubernetes ont une faible empreinte, ce qui permet une consommation de ressources appropriée avec un impact minimal sur le débit, les requêtes par seconde et la latence. Étant donné que les équipes DevOps résistent souvent aux outils de sécurité en raison de la perception qu’ils ralentissent les applications, le choix d’un outil hautes performances avec un faible encombrement peut augmenter la probabilité d’adoption.

Bien qu’un outil qui consolide la protection WAF et DoS puisse sembler plus efficace, il est en réalité susceptible de poser des problèmes d’utilisation du processeur (en raison d’une empreinte plus importante) et de flexibilité. Vous êtes obligé de déployer le WAF et la protection DoS ensemble, même lorsque vous n’avez pas besoin des deux. En fin de compte, ces deux problèmes peuvent augmenter le coût total de possession de vos déploiements Kubernetes tout en créant des défis budgétaires pour d’autres outils et services essentiels.

Une fois que vous avez choisi les bons outils de sécurité pour votre organisation, il est temps de décider où déployer ces outils. Il existe quatre emplacements où les services d'application peuvent généralement être déployés pour protéger les applications Kubernetes :

• À la porte d’entrée (sur un équilibreur de charge externe tel que F5 NGINX Plus ou F5 BIG-IP ) – Idéal pour une protection globale « à granularité grossière », car il vous permet d’appliquer des politiques globales sur plusieurs clusters
• À la périphérie (sur un contrôleur d'entrée tel que le contrôleur d'entrée F5 NGINX ) – Idéal pour fournir une protection « à granularité fine » standard sur un seul cluster
• Au niveau du service (sur un équilibreur de charge léger comme NGINX Plus) – Peut être une approche nécessaire lorsqu'il existe un petit nombre de services au sein d'un cluster qui ont un besoin partagé de politiques uniques
• Au niveau du pod (dans le cadre de l'application) – Une approche très personnalisée qui peut être utilisée lorsque la politique est spécifique à l'application

Alors, parmi les quatre options, laquelle est la meilleure ? Eh bien… ça dépend !

Où déployer un WAF

Tout d’abord, nous examinerons les options de déploiement du WAF, car il s’agit généralement d’un choix plus nuancé.

• Porte d'entrée et périphérie – Si votre organisation préfère une stratégie de sécurité de « défense en profondeur », nous vous recommandons de déployer un WAF à la fois sur l'équilibreur de charge externe et sur le contrôleur d'entrée pour offrir un équilibre efficace entre les protections globales et personnalisées.
• Porte d’entrée ou bordure – En l’absence d’une stratégie de « défense en profondeur », un seul emplacement est acceptable et le lieu de déploiement dépend de la propriété. Lorsqu'une équipe NetOps traditionnelle est responsable de la sécurité, elle peut être plus à l'aise pour la gérer sur un proxy traditionnel (l'équilibreur de charge externe). Cependant, les équipes DevSecOps qui sont à l’aise avec Kubernetes (et préfèrent avoir leur configuration de sécurité à proximité de leurs configurations de cluster) peuvent choisir de déployer un WAF au niveau de l’entrée.
• Par service ou par pod – Si vos équipes ont des exigences spécifiques pour leurs services ou applications, elles peuvent déployer des WAF supplémentaires à la carte. Mais attention : ces emplacements entraînent des coûts plus élevés. Outre un temps de développement accru et un budget cloud plus élevé, ce choix peut également augmenter les coûts opérationnels liés aux efforts de dépannage, par exemple lorsqu'il s'agit de déterminer « Lequel de nos WAF bloque involontairement le trafic ? »

Où déployer la protection DoS

La protection contre les attaques DoS est plus simple car elle n'est nécessaire qu'à un seul endroit, soit à la porte d'entrée, soit au niveau du contrôleur d'entrée. Si vous déployez un WAF à la fois au niveau de la porte d'entrée et de la périphérie, nous vous recommandons de déployer une protection DoS devant le WAF de porte d'entrée, car il est le plus global. De cette façon, le trafic indésirable peut être éliminé avant d'atteindre le WAF, vous permettant ainsi d'utiliser plus efficacement les ressources de calcul.

Pour plus de détails sur chacun de ces scénarios de déploiement, lisez Déploiement de services d’application dans Kubernetes, partie 2 .

Cas d'utilisation : Décharger l'authentification et l'autorisation des applications

Solution: Centraliser l'authentification et l'autorisation au point d'entrée

Une exigence non fonctionnelle courante intégrée aux applications et aux services est l’authentification et l’autorisation. À petite échelle, cette pratique ajoute une quantité gérable de complexité qui est acceptable lorsque l’application ne nécessite pas de mises à jour fréquentes. Mais avec des vitesses de publication plus rapides à plus grande échelle, l’intégration de l’authentification et de l’autorisation dans vos applications devient intenable. S’assurer que chaque application conserve les protocoles d’accès appropriés peut détourner l’attention de la logique métier de l’application ou, pire, peut être négligé et conduire à une violation des informations. Bien que l’utilisation des technologies SSO puisse améliorer la sécurité en éliminant les noms d’utilisateur et les mots de passe distincts au profit d’un seul ensemble d’informations d’identification, les développeurs doivent toujours inclure du code dans leurs applications pour interagir avec le système SSO.

Il existe une meilleure solution : décharger l’authentification et l’autorisation sur un contrôleur d’entrée.

Étant donné que le contrôleur Ingress examine déjà tout le trafic entrant dans le cluster et l’achemine vers les services appropriés, il constitue un choix efficace pour l’authentification et l’autorisation centralisées. Cela supprime la charge des développeurs consistant à créer, maintenir et répliquer la logique dans le code de l'application ; au lieu de cela, ils peuvent rapidement exploiter les technologies SSO au niveau de la couche d'entrée à l'aide de l'API Kubernetes native.

Pour en savoir plus sur ce sujet, lisez Implémentation de l’authentification OpenID Connect pour Kubernetes avec Okta et NGINX Ingress Controller .

Cas d'utilisation : Configurer le libre-service avec Guardrails

Solution: Mettre en œuvre le contrôle d'accès basé sur les rôles (RBAC)

Kubernetes utilise RBAC pour contrôler les ressources et les opérations disponibles pour différents types d'utilisateurs. Il s’agit d’une mesure de sécurité précieuse car elle permet à un administrateur ou à un superutilisateur de déterminer comment les utilisateurs, ou les groupes d’utilisateurs, peuvent interagir avec n’importe quel objet Kubernetes ou espace de noms spécifique dans le cluster.

Bien que RBAC Kubernetes soit activé par défaut, vous devez veiller à ce que vos outils de gestion du trafic Kubernetes soient également compatibles RBAC et puissent s’aligner sur les besoins de sécurité de votre organisation. Avec RBAC en place, les utilisateurs bénéficient d'un accès sécurisé aux fonctionnalités dont ils ont besoin pour faire leur travail sans attendre qu'un ticket soit traité. Mais sans RBAC configuré, les utilisateurs peuvent obtenir des autorisations dont ils n’ont pas besoin ou auxquelles ils n’ont pas droit, ce qui peut entraîner des vulnérabilités si les autorisations sont mal utilisées.

Un contrôleur Ingress est un parfait exemple d'outil pouvant servir de nombreuses personnes et équipes lorsqu'il est configuré avec RBAC. Lorsque le contrôleur Ingress permet une gestion fine des accès (même jusqu'à un seul espace de noms), vous pouvez utiliser RBAC pour permettre une utilisation efficace des ressources via la multilocation.

À titre d’exemple, plusieurs équipes peuvent utiliser le contrôleur Ingress comme suit :

• Équipe NetOps – Configure le point d'entrée externe de l'application (comme le nom d'hôte et les certificats TLS) et délègue les politiques de contrôle du trafic à différentes équipes
• Équipe DevOps A – Fournit des politiques d'équilibrage de charge et de routage TCP/UDP
• Équipe DevOps B – Configure les politiques de limitation de débit pour protéger les services contre les demandes excessives
• Équipe d'identité – Gère les composants d'authentification et d'autorisation tout en configurant les politiques mTLS dans le cadre d'une stratégie de chiffrement de bout en bout
• Équipe DevSecOps – Définit les politiques WAF

Pour savoir comment exploiter RBAC dans NGINX Ingress Controller, regardez Déploiements Kubernetes avancés avec NGINX Ingress Controller . À partir de 13h50, nos experts expliquent comment tirer parti du RBAC et de l’allocation des ressources pour la sécurité, le libre-service et le multi-locataire.

Cas d'utilisation : Mettre en œuvre le chiffrement de bout en bout

Solution: Utiliser des outils de gestion du trafic

Le chiffrement de bout en bout (E2EE) devient une exigence de plus en plus courante pour les organisations qui traitent des informations sensibles ou personnelles. Qu’il s’agisse de données financières ou de messages sur les réseaux sociaux, les attentes des consommateurs en matière de confidentialité, combinées à des réglementations telles que le RGPD et la HIPAA, stimulent la demande pour ce type de protection. La première étape pour atteindre le E2EE consiste soit à concevoir vos applications back-end pour accepter le trafic SSL/TLS, soit à utiliser un outil qui décharge la gestion SSL/TLS de vos applications (l'option préférée pour la séparation de la fonction de sécurité, des performances, de la gestion des clés, etc.). Ensuite, vous configurez vos outils de gestion du trafic en fonction de la complexité de votre environnement.

Scénario le plus courant : E2EE à l'aide d'un contrôleur d'entrée

Lorsque vous avez des applications avec un seul point de terminaison (applications simples ou applications monolithiques que vous avez « soulevées et déplacées » dans Kubernetes) ou qu'il n'y a pas de communication de service à service , vous pouvez utiliser un contrôleur Ingress pour implémenter E2EE dans Kubernetes.

Étape 1 : Assurez-vous que votre contrôleur d'entrée autorise uniquement les connexions SSL/TLS chiffrées à l'aide de certificats côté service ou mTLS, idéalement pour le trafic entrant et sortant.

Étape 2 : Adressez-vous au paramètre par défaut typique qui nécessite que le contrôleur d’entrée déchiffre et rechiffre le trafic avant de l’envoyer aux applications. Cela peut être réalisé de plusieurs manières – la méthode que vous choisissez dépend de votre contrôleur Ingress et de vos exigences :

• Si votre contrôleur Ingress prend en charge le relais SSL/TLS, il peut acheminer les connexions chiffrées SSL/TLS en fonction de l'en-tête SNI (Service Name Indication), sans les déchiffrer ni nécessiter l'accès aux certificats ou clés SSL/TLS.
• Vous pouvez également configurer la terminaison SSL/TLS, où le contrôleur d'entrée met fin au trafic, puis le transmet par proxy aux backends ou aux serveurs en amont, soit en texte clair, soit en rechiffrant le trafic avec mTLS ou SSL/TLS côté service vers vos services Kubernetes.

Scénario moins courant : E2EE à l'aide d'un contrôleur d'entrée et d'un maillage de services

S'il existe une communication de service à service au sein de votre cluster, vous devez implémenter E2EE sur deux plans : le trafic entrant-sortant avec le contrôleur Ingress et le trafic de service à service avec un maillage de services . Dans E2EE, le rôle d'un maillage de services est de garantir que seuls des services spécifiques sont autorisés à communiquer entre eux et qu'ils le font de manière sécurisée. Lorsque vous configurez un maillage de services pour E2EE, vous devez activer un environnement de confiance zéro via deux facteurs : mTLS entre les services (configuré pour exiger un certificat) et le contrôle d'accès au trafic entre les services (dictant quels services sont autorisés à communiquer). Idéalement, vous implémentez également mTLS entre les applications (gérées par un maillage de services et le contrôleur d’entrée-sortie) pour une véritable sécurité E2EE dans l’ensemble du cluster Kubernetes.

Pour en savoir plus sur le chiffrement des données exposées sur le réseau, lisez L'architecture mTLS dans NGINX Service Mesh .

Cas d'utilisation : Assurez-vous que les clients utilisent un chiffrement fort avec une implémentation fiable

Solution: Conformez-vous aux normes fédérales de traitement de l'information (FIPS)

Dans l'industrie du logiciel, FIPS fait généralement référence à la publication spécifiquement consacrée à la cryptographie, FIPS PUB 140-2 Security Requirements for Cryptographic Modules, qui est un effort conjoint entre les États-Unis et le Canada. Il normalise les tests et la certification des modules cryptographiques acceptés par les agences fédérales des deux pays pour la protection des informations sensibles. « Mais attendez ! » dites-vous. « Je ne me soucie pas du FIPS parce que je ne travaille pas avec des entités gouvernementales nord-américaines. » Devenir conforme à la norme FIPS peut être une décision intelligente quel que soit votre secteur d’activité ou votre zone géographique, car la norme FIPS est également la référence cryptographique mondiale de facto.

Se conformer à la norme FIPS ne doit pas être difficile, mais cela nécessite que votre système d’exploitation et les outils de gestion du trafic pertinents puissent fonctionner en mode FIPS. Il existe une idée fausse courante selon laquelle la conformité FIPS est obtenue simplement en exécutant le système d’exploitation en mode FIPS. Même avec le système d’exploitation en mode FIPS, il est toujours possible que les clients communiquant avec votre contrôleur Ingress n’utilisent pas un chiffrement fort. Lorsque vous travaillez en mode FIPS, votre système d'exploitation et votre contrôleur d'entrée peuvent utiliser uniquement un sous-ensemble des chiffrements SSL/TLS classiques.

La configuration de FIPS pour vos déploiements Kubernetes est un processus en quatre étapes :

• Étape 1 : Configurez votre système d'exploitation pour le mode FIPS
• Étape 2 : Vérifiez que le système d'exploitation et OpenSSL sont en mode FIPS
• Étape 3 : Installer le contrôleur Ingress
• Étape 4 : Vérifiez la conformité à la norme FIPS 140-2 en effectuant une vérification du statut FIPS

Dans l'exemple ci-dessous, lorsque le mode FIPS est activé pour le système d'exploitation et l'implémentation OpenSSL utilisée par NGINX Plus, tout le trafic des utilisateurs finaux vers et depuis NGINX Plus est déchiffré et chiffré à l'aide d'un moteur de chiffrement validé et compatible FIPS.

En savoir plus sur FIPS dans Obtenir la conformité FIPS avec NGINX Plus .

Rendre Kubernetes plus sécurisé avec NGINX

Si vous êtes prêt à mettre en œuvre certaines (ou toutes) de ces méthodes de sécurité, vous devez vous assurer que vos outils disposent des fonctionnalités et des capacités appropriées pour prendre en charge vos cas d’utilisation. NGINX peut vous aider avec notre suite d'outils de gestion du trafic Kubernetes prêts pour la production :

• Contrôleur d'entrée NGINX – Contrôleur d'entrée basé sur NGINX Plus pour Kubernetes qui gère le contrôle et la mise en forme avancés du trafic, la surveillance et la visibilité, l'authentification et l'authentification unique, et agit comme une passerelle API.

• F5 NGINX App Protect – Protection holistique pour les applications et API modernes, basée sur les technologies de sécurité de pointe de F5, qui s'intègre à NGINX Ingress Controller et NGINX Plus. Utilisez une approche modulaire pour plus de flexibilité dans les scénarios de déploiement et une utilisation optimale des ressources :

  • NGINX App Protect WAF – Un WAF puissant et léger qui protège contre les OWASP Top 10 et au-delà avec la conformité PCI DDS.

  • NGINX App Protect DoS – Détection et atténuation des attaques DoS comportementales avec une protection cohérente et adaptative sur les clouds et les architectures.

• F5 NGINX Service Mesh – Service mesh léger, clé en main et convivial pour les développeurs avec NGINX Plus comme side-car d'entreprise.

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