Πρέπει κάθε μισθωτής να έχει το δικό του VM;

Περίληψη

Η πολυ-μισθωτική φιλοξενία σας αναγκάζει να επιλέξετε πόσο μακριά μπορούν να φτάσουν οι μισθωτές ο ένας μέσα στον άλλο. Τα κοντέινερ χρησιμοποιούν Linux namespaces και cgroups για να απομονώσουν διεργασίες και πόρους, αλλά μοιράζονται τον πυρήνα του host. Οι εικονικές μηχανές προσθέτουν ένα όριο σε επίπεδο υλικού, με κόστος ταχύτητας και λειτουργικού φόρτου. Μια υβριδική προσέγγιση—κοντέινερ μέσα σε VM—μπορεί να σας δώσει και τα δύο, αλλά διπλασιάζει την επιφάνεια που πρέπει να επιδιορθώσετε. Αυτό το άρθρο σας καθοδηγεί σε μια απόφαση βάσει κινδύνου, μια σύγκριση δίπλα-δίπλα και τα βήματα σκλήρυνσης του Docker που έχουν σημασία ακόμη και μέσα σε ένα VM. Στο τέλος, θα ξέρετε ποιο μοντέλο απομόνωσης ταιριάζει στους μισθωτές σας και τι πρέπει να ρυθμίσετε πριν από την κυκλοφορία.

Η πολυ-μισθωτική σας εφαρμογή είναι σχεδόν έτοιμη. Έχετε ένα αρχείο Docker Compose που δημιουργεί μια στοίβα ανά πελάτη, και είναι γρήγορο. Τότε ένας φίλος που διαχειρίζεται μια εταιρεία φιλοξενίας ρωτά: «Δίνεις σε κάθε μισθωτή το δικό του VM;» Παγώνετε. Δεν είχατε προγραμματίσει αυτή την ερώτηση. Αυτό το άρθρο σας δίνει έναν τρόπο να την απαντήσετε σήμερα, χωρίς ομάδα ασφαλείας. Το κάνετε μόνοι σας, οπότε η απόφαση πρέπει να είναι αρκετά απλή για να την υπερασπιστείτε στις 2 τα ξημερώματα.

Σταματήστε να ψάχνετε το «καλύτερο» μοντέλο. Ξεκινήστε γράφοντας τι συμβαίνει αν ο κώδικας ενός μισθωτή καταλάβει τον host σας. Καθορίστε την ακτίνα έκρηξης προτού επιλέξετε οποιοδήποτε εργαλείο. Αυτή η άσκηση θα σας πει περισσότερα από ό,τι οποιοδήποτε σημείο αναφοράς.

Ο πυρήνας είναι ο συγκάτοικος που δεν μπορείτε να διώξετε

Τα κοντέινερ είναι αποδοτικά επειδή μοιράζονται τον πυρήνα του host. Αυτός ο διαμοιρασμός είναι όλο το κόλπο και όλος ο κίνδυνος. Τα Linux namespaces δίνουν σε κάθε κοντέινερ τη δική του εικόνα των διεργασιών, του δικτύου και του συστήματος αρχείων. Οι ομάδες ελέγχου (cgroups) σας επιτρέπουν να περιορίσετε CPU, μνήμη και I/O δίσκου, έτσι ώστε ένας μισθωτής να μην μπορεί να λιμοκτονήσει τους άλλους. Αλλά κανένα από αυτά δεν δημιουργεί ένα τείχος υλικού.

Σκεφτείτε ένα κοντέινερ ως μια διεργασία με μια πολύ καλή πλαστή ταυτότητα. Πιστεύει ότι βρίσκεται στη δική του μηχανή. Ο πυρήνας, ωστόσο, είναι ένα αντίγραφο του Linux που τρέχει στον host σας. Αν ένας μισθωτής εκμεταλλευτεί μια ευπάθεια του πυρήνα, τα namespaces γίνονται μεταδεδομένα και τίποτα περισσότερο. Ένας εισβολέας που μπορεί να καλέσει συναρτήσεις του πυρήνα μπορεί να φτάσει σε άλλα namespaces στον ίδιο πυρήνα. Αυτή είναι η διαφυγή από κοντέινερ για την οποία ακούτε συνεχώς.

Ας πούμε ότι φιλοξενείτε ένα μικρό εργαλείο B2B με ένα κοντέινερ ανά πελάτη. Ένας πελάτης εγκαθιστά ένα ύποπτο πρόσθετο με ένα σφάλμα απομακρυσμένης εκτέλεσης κώδικα. Με τις προεπιλεγμένες ρυθμίσεις του Docker, αυτή η διεργασία εκτελείται ως root μέσα στο κοντέινερ. Το root σε ένα κοντέινερ είναι ακόμα UID 0, και ο πυρήνας δεν διακρίνει αυτό το UID από το root του host, εκτός αν αντιστοιχίσετε ρητά τους χρήστες. Ο εισβολέας μπορεί να επιχειρήσει να ξεφύγει, και ο κοινόχρηστος πυρήνας είναι ο στόχος του.

Η αποτυχία δεν χρειάζεται να είναι δραματική. Ένας μόνο μισθωτής με διαρροή μνήμης μπορεί να σπρώξει τον host σε swap, επιβραδύνοντας κάθε άλλο μισθωτή. Χωρίς όρια cgroup, ένας κακός βρόχος είναι μια επίθεση διαθεσιμότητας. Με αυτά, είναι μια μπλοκαρισμένη διεργασία και μια ειδοποίηση.

Σημαίνει αυτό ότι τα κοντέινερ δεν είναι ασφαλή; Όχι. Σημαίνει ότι πρέπει να αντιμετωπίζετε τον πυρήνα ως μια κοινή ζώνη εμπιστοσύνης. Πριν επιλέξετε, γράψτε μια δήλωση κινδύνου μιας παραγράφου: «Αν το κοντέινερ ενός μισθωτή παραβιαστεί, ο εισβολέας μπορεί να έχει πρόσβαση σε: [λίστα]. Το επιχειρηματικό κόστος θα ήταν: [ποσό ή αντίκτυπος].» Αν αυτή η παράγραφος σας τρομάζει, δεν είστε παρανοϊκοί. Είστε ειλικρινείς.

Για μια βαθύτερη ματιά στο φάσμα απομόνωσης, από κοινόχρηστα κοντέινερ έως πλήρως ξεχωριστές στοίβες, δείτε τον οδηγό μας για το σχεδιασμό μιας πολυ-μισθωτικής αρχιτεκτονικής Docker.

Τρεις Τρόποι να το Κόψετε (Διαλέξτε Έναν Πριν Αναπτύξετε)

Υπάρχουν στην πραγματικότητα τρεις αρχιτεκτονικές για την απομόνωση πολλαπλών μισθωτών. Κάθε «βέλτιστη πρακτική» είναι ένας συνδυασμός αυτών.

Προσέγγιση	Φράγμα απομόνωσης	Καλύτερα όταν	Πιο δύσκολη προειδοποίηση
Κοντέινερ ανά μισθωτή	Linux namespaces + cgroups	Πολλοί μικροί μισθωτές, χαμηλός κίνδυνος ανά μισθωτή, ανάγκη για πυκνότητα	Ένα εκμεταλλεύσιμο σφάλμα πυρήνα μπορεί να σπάσει κάθε μισθωτή σε αυτόν τον host
Ένα VM ανά μισθωτή	Εικονικοποίηση hypervisor/υλικού	Ρυθμιζόμενα δεδομένα, εχθρικοί μισθωτές, υψηλή αξία ανά μισθωτή	Βαρύτερο, πιο αργή προμήθεια, επιδιορθώνετε ένα λειτουργικό σύστημα ανά μισθωτή
Κοντέινερ μέσα σε VM	Όριο VM γύρω από φόρτους εργασίας σε κοντέινερ	Πυκνότητα συν ένα σκληρό κέλυφος μεταξύ ομάδων	Το κόστος και η λειτουργική επιβάρυνση σχεδόν διπλασιάζονται

Κοντέινερ ανά μισθωτή. Αυτή είναι η προεπιλογή για τους περισσότερους ιδρυτές SaaS. Κάθε μισθωτής παίρνει το δικό του κοντέινερ ή μικρή στοίβα Compose. Η προμήθεια είναι άμεση, οι εικόνες είναι μικρές, το CI/CD είναι απλό. Τα όρια πόρων εμποδίζουν τους θορυβώδεις γείτονες να καταβροχθίσουν τον διακομιστή. Το αντάλλαγμα είναι ο κοινόχρηστος πυρήνας. Αν μπορείτε να κρατήσετε τους φόρτους εργασίας μη προνομιούχους και να επιδιορθώνετε τον host τακτικά, αυτή είναι συχνά η σωστή πρώτη κίνηση.

Μην βάζετε δύο μισθωτές στο ίδιο κοντέινερ. Αυτό είναι κοινόχρηστος πυρήνας συν κοινόχρηστο περιβάλλον εκτέλεσης συν κοινόχρηστο σύστημα αρχείων. Αν ένας μισθωτής ανεβάσει ένα αρχείο που δημιουργεί μια διεργασία, ο άλλος μισθωτής είναι ήδη στον ίδιο πίνακα διεργασιών. Ένα κοντέινερ είναι η μονάδα απομόνωσής σας· κάντε το ένα μισθωτή ανά κοντέινερ.

Τι γίνεται με τη βάση δεδομένων; Αν κάθε μισθωτής συνδέεται σε μία παρουσία MongoDB ή PostgreSQL με τα ίδια διαπιστευτήρια, έχετε ήδη προσθέσει ένα τεράστιο κοινό εξάρτημα. Δώστε σε κάθε μισθωτή ξεχωριστά διαπιστευτήρια και ιδανικά ξεχωριστή βάση δεδομένων ή σχήμα. Τα κοντέινερ απομονώνουν την εφαρμογή· η βάση δεδομένων είναι συχνά η πρώτη διαρροή που θα δοκιμάσει ένας εισβολέας.

Ένα VM ανά μισθωτή. Δώστε σε κάθε μισθωτή μια πλήρη εικονική μηχανή. Ο hypervisor προσθέτει ένα όριο σε επίπεδο υλικού, το οποίο είναι ακριβώς αυτό που πρέπει να διασχίσει μια εκμετάλλευση πυρήνα για να φτάσει στον host. Αυτό έχει σημασία για ρυθμιζόμενα περιβάλλοντα ή όταν οι μισθωτές δεν είναι αξιόπιστοι. Το κόστος είναι η πυκνότητα και ο χρόνος. Τώρα διαχειρίζεστε ένα στόλο λειτουργικών συστημάτων, όχι μόνο κοντέινερ. Κάθε VM χρειάζεται ενημερώσεις, παράγοντες ασφαλείας και παρακολούθηση. Για έναν ανεξάρτητο ιδρυτή, αυτή είναι πραγματική δουλειά.

Μοτίβα που λειτουργούν σε αυτό το επίπεδο: χρησιμοποιήστε υποδομή ως κώδικα για να δημιουργήσετε ένα VM από την ίδια βασική εικόνα, ενσωματώστε ενημερώσεις σε νέες εικόνες αντί να επιδιορθώνετε ζωντανά συστήματα και τερματίστε φόρτους εργασίας που δεν αναγνωρίζετε. Κρατήστε τη θύρα διαχείρισης του VM κλειστή στο διαδίκτυο.

Κοντέινερ μέσα σε VM. Αυτό το υβριδικό σπάνια συζητείται σε οδηγούς για αρχάριους. Τοποθετείτε ένα μικρό VM γύρω από κάθε μισθωτή (ή μικρή ομάδα μισθωτών) και στη συνέχεια εκτελείτε κοντέινερ μέσα σε αυτό το VM. Το VM είναι ένα δοχείο ακτίνας έκρηξης· τα κοντέινερ είναι απλώς αναπτύξιμες μονάδες. Αυτό σας δίνει το σκληρό όριο της εικονικοποίησης και την αναπαραγωγιμότητα των εικόνων. Κοστίζει περισσότερο, επειδή πληρώνετε για την επιβάρυνση της εικονικοποίησης και την ευελιξία των κοντέινερ, αλλά μπορεί να είναι το πιο λογικό μακροπρόθεσμο μοντέλο όταν δεν μπορείτε να εμπιστευτείτε πλήρως τους μισθωτές.

Ένα συνηθισμένο μικρο-παράδειγμα: ένας μισθωτής εκτελεί ένα Node API και έναν εργαζόμενο στο παρασκήνιο. Αντί για ένα τεράστιο κοντέινερ με και τις δύο διεργασίες, χρησιμοποιήστε ένα VM και στη συνέχεια δύο κοντέινερ με διαφορετικά όρια πόρων, ένα κοινόχρηστο δίκτυο και χωρίς άμεση έκθεση στο διαδίκτυο για τον εργαζόμενο. Το VM παρέχει το σκληρό όριο· τα κοντέινερ παρέχουν δομή.

Ποιο πρέπει να επιλέξετε; Ο πίνακας είναι η λίστα σας. Οι επόμενες ενότητες κάνουν την απόφαση συγκεκριμένη.

Αν Επιλέξετε Κοντέινερ, Κάντε Αυτά τα Έξι Πράγματα ή Μην Ασχοληθείτε

Τα κοντέινερ ανά μισθωτή είναι εντάξει εάν αντιμετωπίζετε κάθε κοντέινερ ως πιθανό εισβολέα. Αυτό ξεκινά με τη διαμόρφωση, όχι με ευσεβείς πόθους.

0. Περιορίστε τους πόρους προτού εμπιστευτείτε οποιονδήποτε. Τα cgroups είναι ένας μηχανισμός δικαιοσύνης και μια άμυνα διαθεσιμότητας. Ορίστε --memory και --cpus ανά κοντέινερ. Ένας μισθωτής με διαρροή μνήμης θα πρέπει να χτυπήσει το δικό του όριο, όχι του διακομιστή σας. Αυτό δεν είναι όριο ασφαλείας, αλλά ένας θορυβώδης γείτονας είναι μια επίθεση χωρίς ούτε μία γραμμή κώδικα. Ένα πρακτικό ξεκίνημα: --memory 512m --cpus 0.5. Για μια διεργασία εργαζόμενου, ξεκινήστε χαμηλότερα και κλιμακώστε.

1. Εκτελέστε ως μη root χρήστης. Μην αφήσετε ποτέ τη διεργασία του κοντέινερ να χρησιμοποιήσει UID 0 εκτός αν το χρειάζεστε απόλυτα. Ορίστε έναν χρήστη στο Dockerfile και περάστε το --user ως πρόσθετη προστασία. Ένα εκμεταλλεύσιμο σφάλμα που εκτελείται ως μη προνομιούχος χρήστης έχει πολύ λιγότερα μονοπάτια προς τον πυρήνα. Στο Dockerfile σας, δημιουργήστε έναν χρήστη: RUN useradd -u 10001 app και USER app. Μην το παραλείψετε για να κερδίσετε χρόνο.

2. Αφαιρέστε κάθε δυνατότητα που δεν χρειάζεστε. Οι δυνατότητες Linux χωρίζουν τη δύναμη του root σε μικρά κομμάτια. Οι περισσότερες διαδικτυακές εφαρμογές δεν χρειάζονται σχεδόν καμία. Ξεκινήστε με --cap-drop=ALL και προσθέστε πίσω μόνο ό,τι ξέρετε ότι χρειάζεστε. Ένα κοντέινερ χωρίς CAP_SYS_ADMIN είναι πολύ πιο δύσκολο να χρησιμοποιηθεί για κόλπα με namespaces. Αν η εφαρμογή σας προσπαθεί να δεσμεύσει μια προνομιούχα θύρα, εκτελέστε την σε μια υψηλή θύρα και βάλτε έναν διακομιστή μεσολάβησης μπροστά αντί να παραχωρήσετε NET_BIND_SERVICE.

3. Κάντε το σύστημα αρχείων μόνο για ανάγνωση. Η εφαρμογή σας δεν πρέπει να γράφει στο δικό της επίπεδο κοντέινερ. Τοποθετήστε ένα tmpfs για την κατάσταση. Ένας εισβολέας που δεν μπορεί να γράψει στον δίσκο έχει πολύ πιο δύσκολο έργο να εγκαταστήσει επιμονή. Μια παραβιασμένη εφαρμογή PHP που προσπαθεί να γράψει ένα webshell θα αποτύχει όταν το root filesystem είναι μόνο για ανάγνωση. Μπορείτε να τοποθετήσετε έναν ονομαστικό τόμο για έναν εγγράψιμο κατάλογο που η εφαρμογή σας πραγματικά χρειάζεται.

4. Εφαρμόστε seccomp και AppArmor ή SELinux. Αυτά στέλνουν επικίνδυνα syscalls στον σωρό απορριμμάτων. Το Docker περιλαμβάνει ένα προεπιλεγμένο προφίλ seccomp· χρησιμοποιήστε το. Προσθέστε ένα προφίλ AppArmor για ένα άλλο επίπεδο. Δεν χρειάζεται να γίνετε άριστοι σε κάθε syscall. Πρέπει να αρνηθείτε ό,τι ένας κανονικός web worker δεν απαιτεί ποτέ. Μην εκτελείτε ποτέ με --privileged. Αυτή η σημαία απενεργοποιεί σχεδόν κάθε άμυνα που μόλις εγκαταστήσατε.

5. Τμηματοποιήστε το δίκτυο. Μην δίνετε σε κάθε κοντέινερ διαδρομή προς κάθε άλλο κοντέινερ. Προεπιλεγμένη άρνηση και μετά ανοίξτε μόνο τις θύρες που χρειάζεστε. Ένα παραβιασμένο κοντέινερ βάσης δεδομένων δεν θα πρέπει να μπορεί να σαρώσει τον πίνακα διαχείρισής σας. Αν οι μισθωτές βρίσκονται σε ξεχωριστά δίκτυα, μια παραβίαση σε ένα δίκτυο δεν μπορεί να εξαπλωθεί πλευρικά.

Ένα πρακτικό ξεκίνημα:

docker run --user 10001 --cap-drop=ALL --security-opt no-new-privileges --read-only --tmpfs /tmp:rw,size=64M --security-opt seccomp=default.json --memory 512m --cpus 0.5 myimage

Βάλτε τις ίδιες σημαίες σε ένα αρχείο Compose και εφαρμόστε τις σε κάθε μισθωτή. Αυτό δεν είναι πλήρες, αλλά είναι ένα πολύ ισχυρότερο προεπιλεγμένο από ό,τι σας δίνει το docker run από προεπιλογή.

Για μια βαθύτερη ανάλυση, χρησιμοποιήστε τον αναλυτικό οδηγό σκλήρυνσης για κοντέινερ Docker σε πολυ-μισθωτική φιλοξενία.

Η Ενισχυμένη Απομόνωση Κοντέινερ του Docker Είναι η Εξαίρεση που Πρέπει να Γνωρίζετε

Αν εκτελείτε σε ένα διαχειριζόμενο περιβάλλον Docker, αναζητήστε την Ενισχυμένη Απομόνωση Κοντέινερ (ECI) του Docker. Χρησιμοποιεί απομόνωση user namespace και ένα ασφαλές περιβάλλον εκτέλεσης κοντέινερ στο παρασκήνιο. Το root μέσα σε ένα κοντέινερ αντιστοιχίζεται σε έναν μη προνομιούχο χρήστη στον host, έτσι ακόμη και ένα κοντέινερ που εκτελείται ως root δεν αποκτά προνόμια root του host. Επίσης, μπλοκάρει επικίνδυνες δυνατότητες και syscalls από προεπιλογή. Αυτό δεν είναι κάτι που μπορείτε να αναδημιουργήσετε με λίγες σημαίες στο vanilla Docker. Αν η πλατφόρμα σας το υποστηρίζει, ενεργοποιήστε το. Δεν αφαιρεί την ανάγκη για μη root χρήστες και όρια πόρων, αλλά αλλάζει τα δεδομένα του κινδύνου.

Μπορείτε να προσεγγίσετε μέρος αυτού με την αντιστοίχιση user namespace (userns-remap) στον δαίμονα του Docker. Αυτό δεν είναι τόσο πλήρες όσο ένα ασφαλές περιβάλλον εκτέλεσης, αλλά είναι καλύτερο από το τίποτα. Αν το χρησιμοποιήσετε, επαληθεύστε ότι η αντιστοίχιση UID λειτουργεί προτού το εμπιστευτείτε.

Η Πλάνη του VM: Η Μετάβαση σε Εικονικές Μηχανές Δεν Είναι Σκλήρυνση

Εδώ είναι το αντισυμβατικό μέρος, και είναι το μέρος που οι περισσότεροι παραλείπουν. Αν μεταβείτε σε ένα VM ανά μισθωτή και στη συνέχεια αναπτύξετε τα κανονικά κοντέινερ μέσα σε αυτό, δεν έχετε αφαιρέσει το πρόβλημα ασφάλειας των κοντέινερ. Έχετε προσθέσει ένα ευρύ κλουβί. Η διαφυγή από το κοντέινερ εξακολουθεί να λειτουργεί· ο εισβολέας απλώς προσγειώνεται στο VM αντί στον host. Αυτή είναι μια πραγματική βελτίωση, αλλά εξακολουθείτε να χρειάζεστε τα έξι βήματα.

Η άλλη παγίδα είναι να υποθέσετε ότι το ίδιο το VM είναι ασφαλές. Μια προεπιλεγμένη εικόνα με αδύναμο κωδικό SSH, μη ενημερωμένα βασικά πακέτα ή ανοιχτή θύρα διαχείρισης είναι δώρο. Το όριο του hypervisor έχει σημασία μόνο αν ο επισκέπτης είναι σκληρυμένος και ενημερωμένος. Διαφορετικά, το «ασφαλές VM» σας είναι ένας ταχύτερος δρόμος προς τη διακύβευση, επειδή νιώθετε ασφαλείς και σταματάτε να ελέγχετε.

Αυτό που σας δίνει ένα VM είναι αναγώγιμη ακτίνα έκρηξης. Η καταστροφή ενός μισθωτή παραμένει σε ένα VM. Αυτό που σας κοστίζει είναι ο χρόνος σας. Γίνεστε ο διαχειριστής συστημάτων για τόσα λειτουργικά συστήματα όσοι και οι μισθωτές σας. Αν είστε ανεξάρτητος ιδρυτής που κυκλοφορεί ένα προϊόν, ρωτήστε αν έχετε τις ώρες για να επιδιορθώσετε και να παρακολουθήσετε έναν στόλο. Αν ναι, το VM ανά μισθωτή μπορεί να είναι η σωστή επιλογή. Αν όχι, τα κοντέινερ με ισχυρή σκλήρυνση μπορεί να είναι πιο ειλικρινή.

Επίσης, θυμηθείτε ότι ο host του hypervisor είναι ένας κρίσιμος στόχος. Ένας παραβιασμένος hypervisor μπορεί να δει όλους τους επισκέπτες. Επιδιορθώστε τον host, όχι μόνο τους επισκέπτες. Το VM δεν σας απαλλάσσει από την επιδιόρθωση του host· αυξάνει τα διακυβεύματα αν την παραλείψετε.

Μια προειδοποίηση για το υβριδικό: μην υποθέσετε ότι τα κοντέινερ μέσα σε ένα VM σας δίνουν «δύο επίπεδα ασφάλειας» δωρεάν. Το VM προσθέτει ένα όριο· το κοντέινερ εξακολουθεί να χρειάζεται non-root, δυνατότητες και seccomp. Διαφορετικά, το πρώτο επίπεδο είναι μόνο τόσο ισχυρό όσο το πιο αδύναμο κοντέινερ.

Τέσσερις Ερωτήσεις που Λύνουν τη Διαφωνία σε Δέκα Λεπτά

Μην βελτιστοποιείτε εν κενώ. Κάντε στον εαυτό σας αυτές τις τέσσερις ερωτήσεις με τη σειρά. Γράψτε τις απαντήσεις.

1. Σε τι έχει πρόσβαση ο μισθωτής μου; Αν ένας μισθωτής μπορεί να φτάσει μόνο στη δική του διαδικτυακή εφαρμογή και βάση δεδομένων, τα κοντέινερ ανά μισθωτή με αυστηρούς κανόνες δικτύου είναι υπερασπίσιμα. Αν τα δεδομένα ενός μισθωτή είναι ρυθμιζόμενα ή οικονομικά ευαίσθητα, κινηθείτε προς τα VM.

2. Πόσο θα μου κόστιζε η παραβίαση ενός μισθωτή; Προσθέστε χαμένους πελάτες, νομική έκθεση και εμπιστοσύνη. Αν ο αριθμός είναι μεγαλύτερος από το κόστος λειτουργίας των VM, ξοδέψτε τα χρήματα. Αν όχι, τα κοντέινερ είναι μια λογική επιλογή.

3. Πόσους μισθωτές έχω και πόσο πληρώνουν; Πολλοί μικροί συνδρομητές: η πυκνότητα των κοντέινερ έχει σημασία. Μια χούφτα μεγάλων λογαριασμών: δώστε στον καθένα ένα VM και χρεώστε ανάλογα. Οι μισθωτές που σας πληρώνουν λιγότερο από έναν καφέ δεν θα πρέπει να απαιτούν ο καθένας ένα λειτουργικό σύστημα για διαχείριση.

4. Μπορώ να επιδιορθώνω πράγματα σε προγραμματισμένη βάση; Τα κοντέινερ μοιράζονται έναν πυρήνα host, οπότε η επιδιόρθωση του host προστατεύει όλους. Τα VM πολλαπλασιάζουν τους στόχους επιδιόρθωσης. Αν ξέρετε ότι θα παραλείψετε ενημερώσεις, επιλέξτε την αρχιτεκτονική με λιγότερα κινούμενα μέρη και ισχυρότερες προεπιλογές.

Οι απαντήσεις σας θα ομαδοποιηθούν. Δύο ή περισσότερες απαντήσεις που επικεντρώνονται σε VM σημαίνουν ότι δεν θα έπρεπε να καταφεύγετε εξ ορισμού σε κοντέινερ ανά μισθωτή. Τρεις ή περισσότερες απαντήσεις που επικεντρώνονται σε κοντέινερ σημαίνουν ότι τα VM είναι πρόωρα. Ένα αντιδιαισθητικό αποτέλεσμα: ένας μισθωτής χαμηλού εσόδου με πρόσβαση σε ευαίσθητα δεδομένα εξακολουθεί να χρειάζεται το VM, επειδή το ρυθμιστικό κόστος δεν έχει καμία σχέση με το πόσο πληρώνει.

Στείλτε το Ελάχιστο που Μπορείτε να Εμπιστευτείτε, μετά Κερδίστε Περισσότερη Απομόνωση

Η πρώτη σας αρχιτεκτονική δεν χρειάζεται να είναι η τελική. Ξεκινήστε με την πιο αυστηρή διάταξη που μπορείτε πραγματικά να διατηρήσετε και στη συνέχεια προσθέστε απομόνωση καθώς η βάση των μισθωτών σας το δικαιολογεί. Για τους περισσότερους ανεξάρτητους διαχειριστές, αυτό σημαίνει κοντέινερ ανά μισθωτή με non-root, περιορισμένες δυνατότητες, read-only συστήματα αρχείων, seccomp και τμηματοποίηση δικτύου. Για ρυθμιζόμενους ή υψηλής αξίας μισθωτές, πηγαίνετε κατευθείαν σε ένα VM ανά μισθωτή, με κοντέινερ μόνο ως επίπεδο συσκευασίας στο εσωτερικό.

Ό,τι κι αν επιλέξετε, γράψτε την απόφαση και εξετάστε την ξανά κάθε τρίμηνο. Όταν λάβετε την πρώτη ερώτηση «πρέπει να μετακινήσουμε αυτόν τον μισθωτή σε VM;», θα έχετε μια απάντηση και θα έχετε τη λίστα ελέγχου για να την υποστηρίξετε. Αυτό σημαίνει στην πραγματικότητα απομόνωση: ένα αντιστάθμισμα που διαχειρίζεστε, όχι μια τεχνολογία που αγοράζετε.

Πριν από την κυκλοφορία, διατρέξτε την πρακτική λίστα ελέγχου ασφάλειας απομόνωσης Docker—μετατρέπει αυτές τις αποφάσεις σε μια λίστα που μπορείτε να επαληθεύσετε προτού δείξετε μια σελίδα σε έναν πελάτη.