multi-juicer v10.3.0
Ospitare e gestire più istanze di Juice Shop per sessioni di formazione sulla sicurezza e Capture The Flag.
Organizzare CTF e formazioni sulla sicurezza con OWASP Juice Shop è di solito piuttosto complicato: Juice Shop non è pensato per essere utilizzato da più utenti contemporaneamente. Spiegare a tutti come avviare Juice Shop sulla propria macchina funziona, ma sottrae troppo tempo prezioso.
MultiJuicer ti consente di eseguire istanze separate di Juice Shop per ogni partecipante su un cluster kubernetes centrale, per organizzare eventi senza la necessità di istanze locali di Juice Shop.
Cosa fa:
- crea dinamicamente nuove istanze di Juice Shop quando necessario
- funziona su un singolo dominio, include un LoadBalancer che indirizza il traffico all'istanza di Juice Shop del partecipante
- una piccola e curata classifica che mostra i progressi di tutti i partecipanti
- una comoda pagina di amministrazione per gestire le istanze
- backup e applicazione automatica dei progressi delle sfide in caso di riavvio dei container di Juice Shop
- pulizia automatica delle istanze vecchie e inutilizzate
Per una descrizione dettagliata dell'architettura e dei singoli componenti, consulta la Documentazione dell'architettura.
👉 Nuovo a MultiJuicer? Consulta la panoramica visiva per scoprire come i partecipanti si registrano, ottengono le loro istanze di JuiceShop e come i punteggi vengono tracciati nella classifica.
Installazione
MultiJuicer funziona su kubernetes; per installarlo ti servirà helm
helm install multi-juicer oci://ghcr.io/juice-shop/multi-juicer/helm/multi-juicer
Consulta le note di produzione per una checklist dei valori che probabilmente dovrai configurare prima di utilizzare MultiJuicer in eventi reali.
Per configurare MultiJuicer con il supporto per le sfide AI/LLM di JuiceShop v20+, consulta la guida alla configurazione AI/LLM
Guide all'installazione per specifici Cloud Provider / Ambienti
In generale MultiJuicer funziona praticamente su qualsiasi cluster kubernetes, ma per rendere le cose più semplici per chiunque sia nuovo a kubernetes abbiamo preparato alcune guide su come configurare un cluster kubernetes con MultiJuicer installato per alcuni specifici Cloud provider.
Personalizzare la configurazione
Hai alcune opzioni su come configurare lo stack, con alcune possibilità di personalizzare le istanze di JuiceShop secondo i tuoi gusti. Puoi trovare i valori di configurazione predefiniti in: helm/multi-juicer/values.yaml
Scarica e salva il file e indica a helm di usare il tuo file di configurazione al posto di quello predefinito eseguendo:
helm install -f values.yaml multi-juicer ./multi-juicer/helm/multi-juicer/
Per personalizzare il tema delle istanze JuiceShop e dell'interfaccia MultiJuicer (tema, logo, challenge abilitate, ...), consultare la guida alla personalizzazione di JuiceShop.
Disinstallazione
helm delete multi-juicer
FAQ
Quante risorse di calcolo richiederà il cluster?
Per andare sul sicuro, calcola con:
- 1GB di memoria e 1CPU di overhead, per MultiJuicer stesso
- 384MB e 0.1CPU * numero di partecipanti / team, per le singole istanze JuiceShop
I numeri sopra riflettono i limiti di risorse predefiniti. Questi possono essere modificati, vedi: Personalizzare la configurazione
Quanti utenti può gestire MultiJuicer?
Non esiste un vero limite fisso. (Anche se puoi configurarne uno 😉) Il LoadBalancer personalizzato, attraverso il quale fluisce tutto il traffico per le singole istanze, può essere replicato quanto desideri. Puoi anche collegare un Horizontal Pod Autoscaler per scalare automaticamente il LoadBalancer.
Perché un LoadBalancer personalizzato?
Ci sono alcuni requisiti speciali che non abbiamo trovato facilmente risolvibili con qualsiasi load balancer preesistente:
- Limitare il numero di utenti per un deployment solo ai membri di un determinato team.
- Il cookie del load balancer deve essere sicuro e non facilmente falsificabile per accedere a un'altra istanza.
- Gestire l'avvio di nuove istanze.
Se hai ottime idee su come superare questi problemi senza un load balancer personalizzato, scrivici, ci piacerebbe sentirti!
Perché un deployment Kubernetes separato per ogni team?
Ci sono alcune ottime ragioni per questo:
- La possibilità di eliminare le istanze di un team separatamente. Ridurre in sicurezza, senza rimuovere le istanze dei team attivi, è davvero complicato con un deployment scalato. Puoi solo scegliere la scala desiderata, non quali pod mantenere e quali scartare.
- Per garantire che i pod siano ancora correttamente associati ai team dopo che un pod viene ricreato. Questo non è un problema con deployment separati ed è davvero difficile con deployment scalati.
- La possibilità di incorporare il nome del team nel nome del deployment. Sembra una ragione stupida ma rende il debugging MOLTO più semplice, usando solo
kubectl.
Come gestire JuiceShop facilmente usando kubectl?
Puoi elencare tutti i JuiceShop con le informazioni rilevanti usando la funzionalità custom-columns di 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)
Da dove viene questo progetto
Il progetto è nato presso iteratec, un'azienda tedesca di sviluppo software, per condurre i propri corsi di formazione sulla sicurezza destinati ai propri sviluppatori e ai propri clienti. Il progetto è stato poi reso open source nel 2019 e donato all'organizzazione OWASP / al progetto OWASP Juice Shop nel 2023.