Déplacement de la sécurité vers la gauche avec F5 NGINX App Protect sur Amazon EKS

Selon le rapport « The State of Application Strategy in 2022 » de F5, la transformation numérique de l’entreprise 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, les applications actuelles passant d'architectures monolithiques à des architectures distribuées modernes.

Kubernetes a fait son apparition sur la scène technologique pour une utilisation grand public en 2016, il y a à peine six ans. Pourtant, aujourd’hui, plus de 75 % des organisations dans le monde exécutent des applications conteneurisées en production, soit une augmentation de 30 % par rapport à 2019. L’un des problèmes critiques dans les environnements Kubernetes, y compris Amazon Elastic Kubernetes Service (EKS), est la sécurité. Trop souvent, la sécurité est « ajoutée » à la fin du processus de développement de l’application, et parfois même pas avant qu’une application conteneurisée soit déjà opérationnelle.

La vague actuelle de transformation numérique, accélérée par la pandémie de COVID-19, a obligé de nombreuses entreprises à adopter une approche plus holistique de la sécurité et à envisager une stratégie de « shift left ». Déplacer la sécurité vers la gauche signifie introduire des mesures de sécurité dès le début 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. Il s’agit d’une évolution vers un nouveau paradigme appelé DevSecOps, où la sécurité est ajoutée aux processus DevOps et s’intègre dans les cycles de publication rapides typiques du développement et de la livraison d’applications logicielles modernes.

DevSecOps représente un changement culturel important. Les équipes de sécurité et DevOps travaillent avec un objectif commun : mettre sur le marché des produits de haute qualité rapidement et en toute sécurité. Les développeurs ne se sentent plus bloqués à chaque instant par des procédures de sécurité qui interrompent leur flux de travail. Les équipes de sécurité ne se retrouvent plus à résoudre les mêmes problèmes à plusieurs reprises. Cela permet à l’organisation de maintenir une posture de sécurité solide, en détectant et en prévenant les vulnérabilités, les erreurs de configuration et les violations de conformité ou de politique au fur et à mesure qu’elles se produisent.

Le déplacement de la sécurité vers la gauche et l'automatisation de la sécurité en tant que code protègent votre environnement Amazon EKS dès le départ. Apprendre à devenir prêt pour la production à grande échelle est une partie importante de la construction d’une base Kubernetes. Une gouvernance appropriée d’Amazon EKS contribue à accroître l’efficacité, la transparence et la responsabilité dans l’ensemble de l’entreprise tout en contrôlant les coûts. Une gouvernance solide et des garde-fous de sécurité créent un cadre pour une meilleure visibilité et un meilleur contrôle de vos clusters. Sans eux, votre organisation est exposée à un risque accru de failles de sécurité et aux coûts à long terme qui en découlent, associés à des atteintes aux revenus et à la réputation.

Pour en savoir plus sur les éléments à prendre en compte lors du passage à une stratégie axée sur la sécurité, consultez ce récent rapport d'O'Reilly, Shifting Left for Application Security .

Automatisation de la sécurité pour Amazon EKS avec GitOps

L’automatisation est un élément important pour DevSecOps, aidant à maintenir la cohérence même à un rythme rapide de développement et de déploiement. Tout comme l’infrastructure en tant que code, l’automatisation avec une approche de sécurité en tant que code implique l’utilisation de politiques déclaratives pour maintenir l’état de sécurité souhaité.

GitOps est un cadre opérationnel qui facilite l'automatisation pour soutenir et simplifier la distribution d'applications et la gestion des clusters. L'idée principale de GitOps est d'avoir un référentiel Git qui stocke les politiques déclaratives des objets Kubernetes et des applications exécutées sur Kubernetes, définies sous forme de code. Un processus automatisé complète le paradigme GitOps pour faire en sorte que l'environnement de production corresponde à toutes les descriptions d'état stockées.

Le référentiel agit comme une source de vérité sous la forme de politiques de sécurité, qui sont ensuite référencées par des descriptions de configuration déclaratives en tant que code dans le cadre du processus de pipeline CI/CD. À titre d’exemple, NGINX gère un référentiel GitHub avec un rôle Ansible pour F5 NGINX App Protect qui, nous l’espérons, sera utile pour aider les équipes souhaitant déplacer la sécurité vers la gauche.

Avec un tel référentiel, tout ce qu'il faut pour déployer une nouvelle application ou mettre à jour une application existante est de mettre à jour le référentiel. Le processus automatisé gère tout le reste, y compris l'application des configurations et la garantie que les mises à jour sont réussies. Cela garantit que tout se passe dans le système de contrôle de version pour les développeurs et est synchronisé pour renforcer la sécurité des applications critiques pour l'entreprise.

Lorsqu'il est exécuté sur Amazon EKS, GitOps rend la sécurité transparente et robuste, tout en éliminant pratiquement les erreurs humaines et en gardant une trace 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 de SecOps et de DevOps et inclure des dispositions permettant de s'adapter à l'évolution de l'environnement. Les clusters Kubernetes peuvent être partagés de nombreuses manières. Par exemple, un cluster peut contenir plusieurs applications exécutées et partageant ses ressources, tandis que dans un autre cas, il existe plusieurs instances d'une même application, chacune pour un utilisateur final ou un groupe différent. Cela implique que les limites de sécurité ne sont pas toujours clairement définies et qu’il est nécessaire de mettre en place des politiques de sécurité flexibles et précises.

La conception globale de la sécurité doit être suffisamment flexible pour prendre en charge les exceptions, doit s’intégrer facilement dans le pipeline CI/CD et doit prendre en charge la multilocation. Dans le contexte de Kubernetes, un locataire est un regroupement logique d’objets et d’applications Kubernetes associés à une unité commerciale, une équipe, un cas d’utilisation ou un environnement spécifique. Le multi-hébergement signifie alors que plusieurs locataires partagent en toute sécurité le même cluster, avec des limites entre les locataires appliquées en fonction des exigences de sécurité techniques étroitement liées aux besoins de l'entreprise.

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 et DoS avec NGINX Ingress Controller . Aucun de nos autres concurrents ne propose ce type de solution en ligne. L’utilisation d’un seul produit avec une technologie synchronisée 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 de l'application – Dans un déploiement Kubernetes bien conçu, NGINX Ingress Controller est le seul point d'entrée pour le trafic du plan de données circulant vers les services exécutés dans Kubernetes, ce qui en fait un emplacement idéal pour une protection WAF et DoS.
• Consolidation du plan de données – L’intégration du WAF dans NGINX Ingress Controller élimine le besoin d’un périphérique 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 WAF et DoS peut être gérée avec l'API Kubernetes, ce qui facilite considérablement l'automatisation des processus CI/CD. La configuration du contrôleur d'entrée NGINX est conforme aux pratiques de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes, ce qui vous permet de déléguer en toute sécurité les configurations WAF et DoS à une équipe DevSecOps dédiée.

Les objets de configuration pour NGINX App Protect WAF et DoS sont cohérents entre NGINX Ingress Controller et NGINX Plus . Une configuration principale peut être facilement traduite et déployée sur l'un ou l'autre appareil, ce qui facilite encore plus la gestion de la configuration WAF en tant que code et son déploiement dans n'importe quel environnement d'application.

Pour intégrer NGINX App Protect WAF et DoS dans NGINX Ingress Controller, vous devez disposer d'abonnements pour NGINX Plus et NGINX App Protect WAF ou DoS. Quelques étapes simples suffisent pour créer l’ image intégrée du contrôleur d’entrée NGINX (conteneur Docker). Après avoir déployé l'image ( manuellement ou avec des graphiques Helm , par exemple), vous pouvez gérer les politiques de sécurité et la configuration à l'aide de l'API Kubernetes familière.

Le contrôleur d’entrée NGINX basé sur NGINX Plus fournit un contrôle et une gestion granulaires de l’authentification, de l’autorisation basée sur RBAC et des interactions externes avec les pods. Lorsque le client utilise HTTPS, NGINX Ingress Controller peut mettre fin à TLS et décrypter le trafic pour appliquer le routage de couche 7 et renforcer la 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 en tant que solution de sécurité logicielle légère. NGINX App Protect WAF sécurise les applications Kubernetes contre les 10 principales attaques OWASP et fournit des signatures avancées et une protection contre les menaces, une défense contre les robots et une protection Dataguard contre l'exploitation des informations personnelles identifiables (PII). NGINX App Protect DoS fournit une ligne de défense supplémentaire aux couches 4 et 7 pour atténuer les attaques DoS sophistiquées au niveau de la couche applicative avec une analyse du comportement des utilisateurs et des contrôles de l'état des applications pour se protéger contre les attaques qui incluent Slow POST , Slowloris, les attaques par inondation et Challenger Collapsar.

De telles mesures de sécurité protègent à la fois les API REST et les applications accessibles via des navigateurs Web. La sécurité de l’API est également appliquée au niveau d’entrée suivant le flux de trafic nord-sud.

NGINX Ingress Controller avec NGINX App Protect WAF et DoS peut sécuriser le trafic Amazon EKS par requête plutôt que par service : il s'agit d'une vue plus utile du trafic de couche 7 et d'un bien meilleur moyen d'appliquer les SLA et la sécurité WAF nord-sud.

Le dernier rapport de test de pare-feu d'application Web hautes performances de GigaOm montre comment NGINX App Protect WAF offre systématiquement une sécurité renforcée 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 testés.

À titre d’exemple, la figure 4 montre les résultats d’un test où le WAF a dû gérer 500 requêtes par seconde (RPS), avec 95 % (475 RPS) de requêtes valides et 5 % de requêtes (25 RPS) « mauvaises » (simulant une injection de script). Au 99e percentile, 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 le plus élevé atteint par chaque WAF avec 100 % de réussite (aucun 5xx ou429 erreurs) avec moins de 30 millisecondes de latence pour chaque requête. NGINX App Protect WAF a géré 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 exploitent une approche de 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é dans votre pipeline CI/CD pour le cycle de vie des applications sur Amazon EKS.

NGINX Ingress Controller fournit plusieurs définitions de ressources personnalisées (CRD) pour gérer chaque aspect de la sécurité des applications Web et pour prendre en charge un modèle de responsabilité partagée et multi-locataire. Les manifestes CRD peuvent être appliqués en suivant le regroupement d'espaces de noms utilisé par l'organisation, pour prendre en charge la propriété de plusieurs groupes d'opérations.

Lors de la publication d'une application sur Amazon EKS, vous pouvez intégrer la sécurité en exploitant le pipeline d'automatisation déjà utilisé et en superposant 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 l'utilisation du processeur et de la mémoire, afin d'empêcher NGINX App Protect de priver d'autres processus. Cela est particulièrement important dans les environnements multi-locataires tels que Kubernetes, qui reposent sur le partage des ressources et peuvent potentiellement souffrir du 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 séparés par conception, afin de refléter la manière dont les équipes de sécurité fonctionnent généralement indépendamment de DevOps et des propriétaires d'applications. Vous pouvez envoyer les journaux NGINX App Protect à n'importe quelle destination Syslog accessible à partir des pods Kubernetes, en définissant le paramètre sur l'annotation app-protect-security-log-destination sur l'adresse IP du cluster du pod Syslog. De plus, vous pouvez utiliser la ressource APLogConf pour spécifier les journaux NGINX App Protect qui vous intéressent et, par implication, les journaux qui sont transmis au pod syslog. Les journaux du contrôleur d'entrée NGINX sont transmis à la sortie standard locale, comme pour tous les conteneurs Kubernetes.

Cet exemple de ressource APLogConf spécifie que toutes les demandes sont enregistrées (pas seulement celles malveillantes) et définit les tailles maximales de message et de demande qui peuvent être enregistrées.

apiVersion: appprotect.f5.com/v1beta1 type: APLogConf 
métadonnées : 
nom : logconf 
espace de noms : dvwa 
spécification : 
contenu : 
format : par défaut 
taille_max_message : 64 ko 
max_request_size : tout 
filtre : 
request_type : tous

Définition d'une politique WAF avec les CRD NGINX

L'objet APPolicy Policy est un CRD qui définit une politique de sécurité WAF avec des ensembles de signatures et des règles de sécurité basées sur une approche déclarative. Cette approche s’applique à la fois à NGINX App Protect WAF et DoS, tandis que l’exemple suivant se concentre sur WAF. Les définitions de politique sont généralement stockées dans la source de vérité de l'organisation dans le cadre du catalogue SecOps.

apiVersion: appprotect.f5.com/v1beta1 type: Politique d'application
métadonnées : 
nom : exemple-de-politique
spécification : 
politique : 
nom : exemple-de-politique 
modèle : 
nom : POLICY_TEMPLATE_NGINX_BASE 
applicationLanguage: utf-8 
enforcementMode: blocage 
signature-sets: 
- nom: Signatures d'exécution de commande 
alarme : vrai 
bloc : vrai
[...]

Une fois le manifeste de la politique de sécurité appliqué sur le cluster Amazon EKS, créez un objet APLogConf appelé log-violations pour définir le type et le format des entrées écrites dans le journal lorsqu'une demande viole une politique WAF :

apiVersion: appprotect.f5.com/v1beta1 type: APLogConf 
métadonnées : 
nom : violations du journal
spécification : 
contenu : 
format : par défaut 
taille_max_message : 64k 
max_request_size : tout 
filtre : 
request_type : illégal

L'objet de stratégie waf-policy fait ensuite référence à sample-policy pour NGINX App Protect WAF à appliquer sur le trafic entrant lorsque l'application est exposée par NGINX Ingress Controller. Il fait référence aux violations de journal pour définir le format des entrées de journal envoyées au serveur syslog spécifié dans le champ logDest .

apiVersion: k8s.nginx.org/v1 type: Politique
métadonnées : 
nom : waf-policy 
spécification : 
waf : 
activer : true 
apPolicy : « default/sample-policy » 
securityLog : 
activer : true 
apLogConf : « default/log-violations » 
logDest : « syslog:server=10.105.238.128:5144 »

Le déploiement est terminé lorsque DevOps publie un objet VirtualServer qui configure NGINX Ingress Controller pour exposer l'application sur Amazon EKS :

Version de l'API : k8s.nginx.org/v1kind : VirtualServer
métadonnées :
nom : eshop-vs
spécification :
hôte : eshop.lab.local
politiques :
- nom : default/waf-policy
en amont :
- nom : eshop-upstream
service : eshop-service
port : 80
itinéraires :
- chemin : /
action :
pass : eshop-upstream

L'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, où SecOps fournit un catalogue complet de politiques de sécurité et DevOps s'appuie sur lui pour déplacer la sécurité vers la gauche dès le premier jour. Cela permet aux organisations de passer à une stratégie DevSecOps.

Conclusion

Pour les entreprises disposant d’applications héritées et de solutions de sécurité développées au fil des années, le transfert de la sécurité sur Amazon EKS est probablement un processus progressif. Mais recadrer la sécurité sous forme de code géré et maintenu par l’équipe de sécurité et consommé par DevOps permet de fournir des services plus rapidement et de les rendre prêts pour la production.

Pour sécuriser le trafic nord-sud dans Amazon EKS, vous pouvez exploiter NGINX Ingress Controller intégré à NGINX App Protect WAF pour vous protéger contre les attaques ponctuelles au niveau de la couche 7 et NGINX App Protect DoS pour l'atténuation des attaques DoS au niveau des couches 4 et 7 .

Pour essayer NGINX Ingress Controller avec NGINX App Protect WAF, démarrez un essai gratuit de 30 jours sur AWS Marketplace ou contactez-nous pour discuter de vos cas d'utilisation .

Pour découvrir comment vous pouvez prévenir les failles de sécurité et protéger vos applications Kubernetes à grande échelle à l'aide de NGINX Ingress Controller et de NGINX App Protect WAF et DoS sur Amazon EKS, veuillez télécharger notre eBook, Ajoutez de la sécurité à votre Amazon EKS avec F5 NGINX .

Pour en savoir plus sur la façon dont NGINX App Protect WAF surpasse les WAF natifs pour AWS, Azure et Cloudflare, téléchargez le rapport de test de pare-feu d'application Web haute performance de GigaOm et inscrivez-vous au webinaire du 6 décembre où l'analyste de GigaOm Jake Dolezal examine les résultats.