Selon le rapport The State of Application Strategy in 2022 de F5, la transformation numérique des entreprises continue de s’accélérer à l’échelle mondiale. La plupart des entreprises déploient entre 200 et 1 000 applications réparties sur plusieurs zones cloud, tandis que les applications actuelles abandonnent les architectures monolithiques au profit d’architectures distribuées modernes.
Kubernetes a fait son apparition sur la scène technologique auprès du grand public en 2016, il y a seulement six ans. Pourtant, aujourd’hui, plus de 75 % des organisations dans le monde exécutent des applications conteneurisées en production, soit une hausse de 30 % par rapport à 2019. La sécurité constitue un enjeu majeur dans les environnements Kubernetes, notamment Amazon Elastic Kubernetes Service (EKS). Trop souvent, elle n’est ajoutée qu’à la fin du processus de développement de l’application, voire seulement après la mise en service d’une application conteneurisée.
La vague actuelle de transformation numérique, accélérée par la pandémie de COVID‑19, a contraint de nombreuses entreprises à adopter une approche plus globale de la sécurité et à envisager une stratégie de « décalage à gauche ». Décaler la sécurité vers la gauche consiste à intégrer des mesures de sécurité dès les premières étapes du cycle de vie du développement logiciel (SDLC) et à utiliser des outils et des contrôles de sécurité à chaque étape du pipeline CI/CD pour les applications, les conteneurs, les microservices et les API. Cette approche marque le passage à un nouveau paradigme appelé DevSecOps, dans lequel la sécurité est ajoutée aux processus DevOps et intégrée aux cycles de publication rapides caractéristiques du développement et de la livraison des applications logicielles modernes.
Le DevSecOps représente un changement culturel majeur. Les équipes de sécurité et DevOps œuvrent dans un but commun : commercialiser rapidement et en toute sécurité des produits de haute qualité. Les développeurs ne se sentent plus constamment entravés par des procédures de sécurité qui interrompent leur flux de travail. Les équipes de sécurité n’ont plus à corriger sans cesse les mêmes problèmes. L’organisation peut ainsi maintenir un niveau de sécurité élevé en détectant et en prévenant les vulnérabilités, les erreurs de configuration et les manquements aux exigences de conformité ou aux politiques internes dès qu’ils surviennent.
L’intégration de la sécurité en amont et son automatisation sous forme de code protègent votre environnement Amazon EKS dès le départ. Apprendre à être prêt pour la production à grande échelle constitue une étape essentielle dans la mise en place d’une infrastructure Kubernetes. Une gouvernance appropriée d’Amazon EKS contribue à améliorer l’efficacité, la transparence et la responsabilisation dans toute l’entreprise, tout en maîtrisant les coûts. Une gouvernance solide et des garde-fous de sécurité offrent un cadre permettant d’améliorer la visibilité et le contrôle de vos clusters. Sans eux, votre organisation s’expose à un risque accru de failles de sécurité et aux coûts à long terme qui en découlent, notamment en raison de leurs répercussions sur le chiffre d’affaires et la réputation.
Pour en savoir plus sur les éléments à prendre en compte lors de l’adoption d’une stratégie axée en priorité sur la sécurité, consultez ce récent rapport d’O’Reilly, intitulé « Décaler la sécurité des applications en amont ».
Automatiser la sécurité d’Amazon EKS avec GitOps
L’automatisation est un levier essentiel du DevSecOps, car elle permet de maintenir la cohérence, même lorsque le développement et le déploiement s’effectuent à un rythme soutenu. À l’instar de l’infrastructure en tant que code, l’automatisation fondée sur une approche de sécurité en tant que code implique l’utilisation de politiques déclaratives afin de maintenir l’état de sécurité souhaité.
GitOps est un cadre opérationnel qui facilite l’automatisation afin de simplifier la livraison des applications et la gestion des clusters. Le principe fondamental de GitOps consiste à disposer d’un dépôt Git qui stocke, sous forme de code, les politiques déclaratives des objets Kubernetes et des applications exécutées sur Kubernetes. Un processus automatisé complète le paradigme GitOps en veillant à ce que l’environnement de production corresponde à toutes les descriptions d’état stockées.
Le référentiel fait office de source de vérité sous la forme de politiques de sécurité, auxquelles font ensuite référence des descriptions déclaratives de configuration en tant que code dans le cadre du processus de pipeline CI/CD. Par exemple, NGINX gère un référentiel GitHub comprenant un rôle Ansible pour F5 NGINX App Protect qui, nous l’espérons, aidera les équipes souhaitant intégrer la sécurité plus en amont.
Avec un tel dépôt, il suffit de le mettre à jour pour déployer une nouvelle application ou actualiser une application existante. Le processus automatisé se charge de tout le reste, notamment d’appliquer les configurations et de vérifier que les mises à jour ont bien abouti. Ainsi, toutes les opérations sont effectuées dans le système de gestion de versions utilisé par les développeurs et synchronisées afin de garantir la sécurité des applications critiques pour l’entreprise.
Lorsqu’il s’exécute sur Amazon EKS, GitOps rend la sécurité à la fois fluide et robuste, tout en éliminant pratiquement les erreurs humaines et en assurant le suivi de toutes les modifications de version appliquées au fil du temps.
NGINX App Protect et NGINX Ingress Controller protègent vos applications et API dans Amazon EKS
Une conception robuste de la politique de sécurité Kubernetes doit répondre aux besoins des équipes SecOps et DevOps, tout en prévoyant des mécanismes d’adaptation à mesure que l’environnement évolue. Les clusters Kubernetes peuvent être partagés de nombreuses façons. Par exemple, un cluster peut héberger plusieurs applications qui partagent ses ressources, tandis que, dans un autre cas, plusieurs instances d’une même application peuvent être déployées, chacune étant destinée à un utilisateur final ou à un groupe différent. Cela signifie que les périmètres de sécurité ne sont pas toujours clairement définis et qu’il est nécessaire de disposer de politiques de sécurité flexibles et granulaires.
La conception globale de la sécurité doit être suffisamment souple pour prendre en charge les exceptions, s’intégrer facilement au pipeline CI/CD et permettre la mutualisation. Dans le contexte de Kubernetes, un locataire est un regroupement logique d’objets et d’applications Kubernetes associés à une unité opérationnelle, une équipe, un cas d’usage ou un environnement spécifique. La mutualisation désigne donc le partage sécurisé d’un même cluster entre plusieurs locataires, les frontières entre ceux-ci étant appliquées selon des exigences techniques de sécurité étroitement liées aux besoins métier.
Un moyen simple de mettre en œuvre une sécurité à faible latence et hautes performances sur Amazon EKS consiste à intégrer les modules NGINX App Protect WAF and DoS à NGINX Ingress Controller. Aucun de nos autres concurrents ne propose ce type de solution intégrée. L’utilisation d’un produit unique reposant sur des technologies synchronisées offre plusieurs avantages, notamment une réduction du temps de calcul, des coûts et de la prolifération des outils. Voici quelques avantages supplémentaires.
- Sécurisation du périmètre applicatif – Dans un déploiement Kubernetes bien architecturé, NGINX Ingress Controller constitue l’unique point d’entrée du trafic du plan de données à destination des services exécutés dans Kubernetes, ce qui en fait un emplacement idéal pour assurer une protection WAF et contre les attaques DoS.
- Consolidation du plan de données – L’intégration du WAF à NGINX Ingress Controller élimine le besoin d’un dispositif WAF distinct. Cela réduit la complexité, les coûts et le nombre de points de défaillance.
- Consolidation du plan de contrôle – La configuration du WAF et de la protection contre les attaques DoS peut être gérée à l’aide de l’API Kubernetes, ce qui facilite considérablement l’automatisation des processus CI/CD. La configuration de NGINX Ingress Controller respecte les pratiques de contrôle d’accès basé sur les rôles (RBAC) de Kubernetes. Vous pouvez ainsi déléguer en toute sécurité les configurations du WAF et de la protection contre les attaques DoS à une équipe DevSecOps dédiée.
Les objets de configuration de NGINX App Protect WAF et de la protection contre les attaques DoS sont cohérents dans NGINX Ingress Controller comme dans NGINX Plus. Une configuration principale peut facilement être convertie et déployée sur l’un ou l’autre, ce qui simplifie encore davantage la gestion de la configuration WAF sous forme de code et son déploiement dans n’importe quel environnement applicatif.
Pour intégrer NGINX App Protect WAF et DoS à NGINX Ingress Controller, vous devez disposer d’abonnements à NGINX Plus ainsi qu’à NGINX App Protect WAF ou DoS. Quelques étapes simples suffisent pour créer l’image NGINX Ingress Controller intégrée (conteneur Docker). Après avoir déployé l’image (manuellement ou à l’aide de charts Helm, par exemple), vous pouvez gérer les politiques de sécurité et la configuration à l’aide de l’API Kubernetes habituelle.
Le contrôleur d’entrée NGINX basé sur NGINX Plus permet de contrôler et de gérer avec précision l’authentification, les autorisations basées sur le RBAC et les interactions externes avec les pods. Lorsque le client utilise HTTPS, le contrôleur d’entrée NGINX peut mettre fin à la connexion TLS et déchiffrer le trafic afin d’appliquer le routage de couche 7 et les règles de sécurité.
NGINX App Protect WAF et NGINX App Protect DoS peuvent ensuite être déployés pour appliquer des politiques de sécurité afin de se protéger contre les attaques ponctuelles au niveau de la couche 7, sous la forme d’une solution de sécurité logicielle légère. NGINX App Protect WAF protège les applications Kubernetes contre les attaques du Top 10 de l’OWASP et fournit des signatures avancées ainsi qu’une protection contre les menaces, les bots et, grâce à Dataguard, l’exploitation des informations personnelles identifiables (PII). NGINX App Protect DoS offre une ligne de défense supplémentaire au niveau des couches 4 et 7 afin d’atténuer les attaques DoS sophistiquées ciblant la couche applicative, grâce à l’analyse du comportement des utilisateurs et à des contrôles de l’état de santé des applications. Il protège notamment contre les attaques Slow POST, Slowloris, par inondation et Challenger Collapsar.
Ces mesures de sécurité protègent à la fois les API REST et les applications accessibles à l’aide de navigateurs web. La sécurité des API est également appliquée au niveau de l’Ingress, conformément au flux de trafic nord-sud.
NGINX Ingress Controller avec NGINX App Protect WAF et DoS peut sécuriser le trafic Amazon EKS requête par requête plutôt que service par service : cette approche offre une vision plus pertinente du trafic de couche 7 et permet de bien mieux faire respecter les SLA et la sécurité WAF des flux nord-sud.
Le dernier rapport Tests de pare-feu d’applications Web haute performance de GigaOm montre comment NGINX App Protect WAF assure systématiquement une protection robuste des applications et des API, tout en maintenant des performances élevées et une faible latence, surpassant les trois autres WAF testés – AWS WAF, Azure WAF et Cloudflare WAF – à tous les taux d’attaque évalués.
À titre d’exemple, la figure 4 présente les résultats d’un test au cours duquel le WAF devait traiter 500 requêtes par seconde (RPS), dont 95 % (475 RPS) étaient valides et 5 % (25 RPS) étaient « malveillantes » (simulation d’une injection de script). Au 99e centile, la latence de NGINX App Protect WAF était 10 fois inférieure à celle d’AWS WAF, 60 fois inférieure à celle de Cloudflare WAF et 120 fois inférieure à celle d’Azure WAF.
La figure 5 montre le débit maximal atteint par chaque WAF avec un taux de réussite de 100 % (aucune erreur 5xx ou 429) et une latence inférieure à 30 millisecondes pour chaque requête. NGINX App Protect WAF a traité 19 000 RPS, contre 14 000 RPS pour Cloudflare WAF, 6 000 RPS pour AWS WAF et seulement 2 000 RPS pour Azure WAF.
Comment déployer NGINX App Protect et NGINX Ingress Controller sur Amazon EKS
NGINX App Protect WAF et DoS s’appuient sur une approche de la sécurité centrée sur les applications, avec des configurations et des politiques de sécurité entièrement déclaratives, ce qui facilite l’intégration de la sécurité à votre pipeline CI/CD tout au long du cycle de vie des applications sur Amazon EKS.
NGINX Ingress Controller fournit plusieurs définitions de ressources personnalisées (CRD) permettant de gérer tous les aspects de la sécurité des applications web et de prendre en charge un modèle de responsabilité partagée et mutualisé. Les manifestes CRD peuvent être appliqués selon le regroupement des espaces de noms utilisé par l’organisation, afin que plusieurs groupes d’exploitation puissent en être responsables.
Lorsque vous publiez une application sur Amazon EKS, vous pouvez intégrer la sécurité en vous appuyant sur le pipeline d’automatisation déjà utilisé et en y ajoutant la politique de sécurité WAF.
De plus, avec NGINX App Protect sur NGINX Ingress Controller, vous pouvez configurer des seuils d’utilisation des ressources pour le processeur et la mémoire, afin d’éviter que NGINX App Protect ne prive les autres processus de ressources. Cela est particulièrement important dans les environnements mutualisés tels que Kubernetes, qui reposent sur le partage des ressources et peuvent être confrontés au problème du « voisin bruyant ».
Configuration de la journalisation avec les CRD NGINX
Les journaux de NGINX App Protect et de NGINX Ingress Controller sont distincts par conception, afin de refléter le fait que les équipes de sécurité travaillent généralement indépendamment des équipes DevOps et des responsables d’applications. Vous pouvez envoyer les journaux de NGINX App Protect vers toute destination syslog accessible depuis les pods Kubernetes, en définissant le paramètre de l’annotation app-protect-security-log-destination sur l’adresse IP de cluster du pod syslog. Vous pouvez également utiliser la ressource APLogConf pour préciser les journaux de NGINX App Protect qui vous intéressent et, par conséquent, ceux qui sont envoyés au pod syslog. Les journaux de NGINX Ingress Controller sont redirigés vers la sortie standard locale, comme pour tous les conteneurs Kubernetes.
Cet exemple de ressource APLogConf indique que toutes les requêtes sont journalisées (et pas uniquement les requêtes malveillantes) et définit la taille maximale des messages et des requêtes pouvant être journalisés.
apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf
metadata:
name: logconf
namespace: dvwa
spec:
content:
format: default
max_message_size: 64k
max_request_size: any
filter:
request_type: allDéfinition d’une politique WAF avec les CRD NGINX
L’objet de stratégie « APPolicy » est une CRD qui définit une stratégie de sécurité WAF comprenant des ensembles de signatures et des règles de sécurité selon une approche déclarative. Cette approche s’applique à la fois à NGINX App Protect WAF et à la protection DoS, tandis que l’exemple suivant porte sur le WAF. Les définitions de stratégies sont généralement stockées dans la source de référence de l’organisation, au sein du catalogue SecOps.
apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy
metadata:
name: sample-policy
spec:
policy:
name: sample-policy
template:
name: POLICY_TEMPLATE_NGINX_BASE
applicationLanguage: utf-8
enforcementMode: blocking
signature-sets:
- name: Command Execution Signatures
alarm: true
block: true
[...]Une fois le manifeste de la politique de sécurité appliqué au cluster Amazon EKS, créez un objet APLogConf nommé « log-violations » afin de définir le type et le format des entrées consignées dans le journal lorsqu’une requête enfreint une politique WAF :
apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf
metadata:
name: log-violations
spec:
content:
format: default
max_message_size: 64k
max_request_size: any
filter:
request_type: illegalL’objet Policy waf-policy référence ensuite sample-policy afin que NGINX App Protect WAF l’applique au trafic entrant lorsque l’application est exposée par NGINX Ingress Controller. Il référence log-violations pour définir le format des entrées de journal envoyées au serveur syslog indiqué dans le champ logDest.
apiVersion: k8s.nginx.org/v1 kind: Policy
metadata:
name: waf-policy
spec:
waf:
enable: true
apPolicy: "default/sample-policy"
securityLog:
enable: true
apLogConf: "default/log-violations"
logDest: "syslog:server=10.105.238.128:5144"Le déploiement est terminé lorsque l’équipe DevOps publie un objet « VirtualServer » qui configure NGINX Ingress Controller afin de rendre l’application accessible sur Amazon EKS :
apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: eshop-vs
spec:
host: eshop.lab.local
policies:
- name: default/waf-policy
upstreams:
- name: eshop-upstream
service: eshop-service
port: 80
routes:
- path: /
action:
pass: eshop-upstreamL’objet VirtualServer facilite la publication et la sécurisation des applications conteneurisées exécutées sur Amazon EKS, tout en respectant le modèle de responsabilité partagée, dans lequel les équipes SecOps fournissent un catalogue complet de politiques de sécurité sur lequel les équipes DevOps s’appuient pour intégrer la sécurité en amont dès le premier jour. Les organisations peuvent ainsi adopter une stratégie DevSecOps.
Conclusion
Pour les entreprises qui disposent d’applications héritées et de solutions de sécurité accumulées au fil des années, l’intégration de la sécurité en amont sur Amazon EKS sera probablement un processus progressif. Toutefois, repenser la sécurité sous forme de code géré et maintenu par l’équipe de sécurité, puis utilisé par les équipes DevOps, permet de fournir des services plus rapidement et de les préparer à la mise en production.
Pour sécuriser le trafic nord-sud dans Amazon EKS, vous pouvez utiliser NGINX Ingress Controller intégrant NGINX App Protect WAF afin de vous protéger contre les attaques ponctuelles au niveau de la couche 7, ainsi que NGINX App Protect DoS pour atténuer les attaques par déni de service au niveau des couches 4 et 7.
Pour essayer NGINX Ingress Controller avec NGINX App Protect WAF, commencez un essai gratuit de 30 jours sur AWS Marketplace ou contactez-nous pour discuter de vos cas d’usage.
Pour découvrir comment prévenir les failles de sécurité et protéger à grande échelle vos applications Kubernetes à l’aide de NGINX Ingress Controller et de NGINX App Protect WAF and DoS sur Amazon EKS, téléchargez notre livre numérique, « Sécurisez votre environnement Amazon EKS avec F5 NGINX ».
Pour en savoir plus sur la façon dont NGINX App Protect WAF surpasse les WAF natifs d’AWS, d’Azure et de Cloudflare, téléchargez le rapport « Tests de pare-feu d’applications web hautes performances » de GigaOm et inscrivez-vous au webinaire du 6 décembre, au cours duquel Jake Dolezal, analyste chez GigaOm, passera en revue les résultats.
À propos des auteurs
Articles de blog associés
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 ?
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
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
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
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
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.