
multi-juicer v10.3.0
Héberger et gérer plusieurs instances Juice Shop pour des formations en sécurité et des Capture The Flags.
Organiser des CTF et des formations à la sécurité avec OWASP Juice Shop est généralement assez délicat, Juice Shop n'étant tout simplement pas conçu pour être utilisé par plusieurs utilisateurs à la fois. Expliquer à chacun comment démarrer Juice Shop sur sa propre machine fonctionne, mais cela fait perdre beaucoup de temps précieux.
MultiJuicer vous permet d'exécuter des instances Juice Shop distinctes pour chaque participant sur un cluster kubernetes central, afin d'organiser des événements sans avoir besoin d'instances Juice Shop locales.
Ce qu'il fait :
- crée dynamiquement de nouvelles instances Juice Shop lorsque nécessaire
- fonctionne sur un seul domaine, avec un LoadBalancer qui achemine le trafic vers l'instance Juice Shop du participant
- un petit classement bien pratique affichant la progression de tous les participants
- une page d'administration pratique pour gérer les instances
- sauvegarde et réapplication automatique de la progression des défis en cas de redémarrage du conteneur Juice Shop
- nettoyage automatique des anciennes instances inutilisées
Pour une description détaillée de l'architecture et des différents composants, consultez la documentation d'architecture.
👉 Nouveau sur MultiJuicer ? Consultez la visite guidée visuelle pour découvrir comment les participants s'inscrivent, obtiennent leurs instances JuiceShop et comment les scores sont suivis sur le tableau de bord.
Installation
MultiJuicer s'exécute sur kubernetes ; pour l'installer, vous aurez besoin de helm
helm install multi-juicer oci://ghcr.io/juice-shop/multi-juicer/helm/multi-juicer
Consultez les notes de production pour une liste de vérification des valeurs que vous devrez probablement configurer avant d'utiliser MultiJuicer lors d'événements réels.
Pour configurer MultiJuicer avec la prise en charge des défis liés à l'IA/LLM de JuiceShop v20+, consultez le guide de configuration IA/LLM
Guides d'installation pour des fournisseurs cloud / environnements spécifiques
De manière générale, MultiJuicer fonctionne sur à peu près n'importe quel cluster Kubernetes, mais pour faciliter la tâche à toute personne qui débute avec Kubernetes, nous avons rédigé quelques guides sur la façon de configurer un cluster Kubernetes avec MultiJuicer installé pour certains fournisseurs cloud spécifiques.
Personnalisation de l'installation
Vous disposez de plusieurs options pour configurer la pile, avec certaines options permettant de personnaliser les instances JuiceShop selon vos préférences. Vous pouvez trouver les valeurs de configuration par défaut sous : helm/multi-juicer/values.yaml
Téléchargez et enregistrez le fichier, puis indiquez à helm d'utiliser votre fichier de configuration à la place de celui par défaut en exécutant :
helm install -f values.yaml multi-juicer ./multi-juicer/helm/multi-juicer/
Pour personnaliser le thème des instances JuiceShop et de l'interface MultiJuicer (thème, logo, défis activés, ...), consultez le guide de personnalisation JuiceShop.
Désinstallation
helm delete multi-juicer
FAQ
De quelles ressources de calcul le cluster aura-t-il besoin ?
Pour être prudent, calculez avec :
- 1 Go de mémoire et 1 CPU de surcoût, pour MultiJuicer lui-même
- 384 Mo et 0,1 CPU * nombre de participants / équipes, pour les instances JuiceShop individuelles
Les chiffres ci-dessus reflètent les limites de ressources par défaut. Celles-ci peuvent être ajustées, voir : Personnalisation de l'installation
Combien d'utilisateurs MultiJuicer peut-il gérer ?
Il n'y a pas de véritable limite fixe. (Même si vous pouvez en configurer une 😉) Le LoadBalancer personnalisé, par lequel transite tout le trafic des instances individuelles, peut être répliqué autant que vous le souhaitez. Vous pouvez également attacher un Horizontal Pod Autoscaler pour mettre à l'échelle automatiquement le LoadBalancer.
Pourquoi un LoadBalancer personnalisé ?
Il existe certaines exigences particulières pour lesquelles nous n'avons pas trouvé de solution simple avec un load balancer préexistant :
- Restreindre le nombre d'utilisateurs d'un déploiement aux seuls membres d'une équipe donnée.
- Le cookie du load balancer doit être sûr et difficile à usurper pour accéder à une autre instance.
- Gérer le démarrage de nouvelles instances.
Si vous avez d'excellentes idées pour résoudre ces problèmes sans load balancer personnalisé, écrivez-nous, nous serions ravis de vous lire !
Pourquoi un déploiement Kubernetes séparé pour chaque équipe ?
Il y a de très bonnes raisons à cela :
- La possibilité de supprimer les instances d'une équipe séparément. Réduire l'échelle en toute sécurité, sans supprimer les instances des équipes actives, est vraiment délicat avec un déploiement mis à l'échelle. Vous ne pouvez choisir que l'échelle souhaitée, pas quels pods conserver et lesquels supprimer.
- Garantir que les pods restent correctement associés aux équipes après la recréation d'un pod. Ce n'est pas un problème avec des déploiements séparés et c'est vraiment difficile avec des déploiements mis à l'échelle.
- La possibilité d'intégrer le nom de l'équipe dans le nom du déploiement. Cela peut sembler une raison stupide, mais cela rend le débogage TELLEMENT plus facile, rien qu'en utilisant
kubectl.
Comment gérer facilement JuiceShop avec kubectl ?
Vous pouvez lister tous les JuiceShops avec les informations pertinentes en utilisant la fonctionnalité custom-columns de kubectl.
$ kubectl get -l app.kubernetes.io/name=juice-shop -o custom-columns="TEAM:metadata.labels.team,SOLVED-CHALLENGES:metadata.annotations.multi-juicer\.owasp-juice\.shop/challengesSolved,LAST-REQUEST:metadata.annotations.multi-juicer\.owasp-juice\.shop/lastRequestReadable" deployments
TEAM SOLVED-CHALLENGES LAST-REQUEST
foobar 3 Wed May 4 2042 18:14:22 GMT+0000 (Coordinated Universal Time)
team-42 0 Wed May 4 2042 18:14:30 GMT+0000 (Coordinated Universal Time)
the-empire 0 Wed May 4 2042 18:14:46 GMT+0000 (Coordinated Universal Time)