Immagini container minimali

Cos’è Immagini container minimali?

Un'immagine di produzione che contiene un gestore di pacchetti, un compilatore, una shell e utilità di rete trasforma un difetto applicativo limitato in un toolkit funzionante. L'aggressore non porta nulla; l'immagine l'ha già spedita. Utilizzerai un comando da un bug del servizio di pagamento per trovare curl e leggere le credenziali del ruolo dell'istanza dall'endpoint dei metadati su 169.254.169.254. Quindi dividerai la build in due fasi, copierai solo l'artefatto compilato in un'immagine finale senza distro e guarderai una shell che non riesce ad aprirsi nel contenitore ridistribuito perché non ce n'è.

Cosa imparerai in Immagini container minimali

• Riconoscere che una shell, un gestore di pacchetti, un compilatore e gli strumenti di rete forniti in un'immagine runtime diventano il toolkit di un utente malintenzionato
• Traccia come un comando di un difetto dell'applicazione utilizza l'arricciatura fornita per leggere le credenziali del ruolo dell'istanza da 169.254.169.254
• Configura una build in più fasi che mantenga gli strumenti di build nella fase di build e copi solo l'artefatto compilato
• Applicare un'immagine finale senza distribuzione e verificare che non sia possibile aprire una shell nel contenitore ridistribuito
• Spiegare come la rimozione della shell e del gestore pacchetti interrompe il percorso più semplice dall'esecuzione limitata del codice al controllo

Immagini container minimali — Fasi della formazione

1. Un punto d'appoggio nel checkout

   Bob non parte con una shell. Il servizio di checkout costruisce etichette di spedizione in PDF ed esegue comandi esterni per farlo, e un campo di quella richiesta non è sanificato. Inietta una sonda per confermare di poter eseguire un comando, e per vedere chi è e dove si trova.

2. Tutto ciò che l'immagine distribuisce

   Bob ha l'esecuzione di un comando alla volta come l'app, ma non ancora una shell. Di solito è qui che un attaccante si blocca, a meno che il container non gli fornisca un kit di strumenti. Prima di fare qualcosa di rumoroso, controlla cosa è già installato.

3. Recupera le credenziali cloud con curl

   Il container gira nel cloud, e ogni istanza cloud espone un servizio di metadata a un indirizzo interno fisso che distribuisce le credenziali temporanee del ruolo della macchina. Raggiungerlo richiede un client HTTP. L'immagine ne aveva già uno.

4. Come un comando è diventato una violazione

   L'accesso di Bob all'app era strettamente limitato.

5. Una shell in un container runtime

   Skelwyn esegue endpoint detection sui suoi host container. Non sa a cosa serva ogni container; riporta comportamenti che non si addicono a un runtime.

6. Conferma cosa era presente

   Alice riproduce ciò che l'attaccante ha trovato: chiede al container in esecuzione quali di quegli strumenti effettivamente contiene.

7. Un runtime da 412MB

   Il kit di strumenti non è gratuito. È peso, ed è superficie d'attacco. Alice controlla la dimensione dell'immagine effettivamente eseguita dal servizio.

8. Da dove entra il kit di strumenti

   L'immagine è costruita a partire da un unico Dockerfile. Alice lo apre per vedere perché un container runtime finisce per portare con sé un compilatore.

9. Uno stage solo, tutto viene distribuito

   L'immagine viene costruita ed eseguita in un unico stage, quindi tutto ciò di cui la build ha bisogno, lo porta con sé anche il runtime.

10. Separa la build dal runtime

    La correzione è una build multi-stage: mantieni l'immagine completa e la sua toolchain come stage di build che compila l'app, poi copia solo l'app completata e le sue dipendenze in un'immagine runtime distroless che non ha shell, né package manager, né compilatore.