Podman, KVM και κοντέινερ: ένας πρακτικός οδηγός για ασφαλή εικονικοποίηση

Informatec Digital » Πόροι » Podman, KVM και κοντέινερ: ένας πρακτικός οδηγός για ασφαλή εικονικοποίηση

Όταν ξεκινάτε να δημιουργείτε ένα σοβαρό περιβάλλον κοντέινερ σε Linux, προκύπτει αμέσως το ίδιο ερώτημα: σε ποιο βαθμό είναι ασφαλές να βασίζεστε αποκλειστικά σε κοντέινερ και πότε είναι σκόπιμο να κάνετε αναβάθμιση σε KVM ή micro-VM; Σε εταιρικά περιβάλλοντα, όπου συνδυάζονται εικονικές μηχανές Docker, Podman, LXC, KVM και διάφοροι hypervisors, η καλή κατανόηση του μοντέλου απομόνωσης είναι το κλειδί για την αποφυγή λαθών.

Επιπλέον, δεν είναι ασυνήθιστα σενάρια με κάπως περίπλοκο τρόπο, όπως η προσπάθεια χρήσης του Docker Desktop ή του Podman μέσα σε μια εικονική μηχανή στο VirtualBox ή το KVM , όπου ενεργοποιούνται πολλά επίπεδα εικονικοποίησης (ενσωματωμένα ή όχι) και είναι εύκολο να αντιμετωπίσετε σφάλματα όπως "Το KVM δεν είναι ενεργοποιημένο στον κεντρικό υπολογιστή". Ας οργανώσουμε όλα αυτά τα κομμάτια - κοντέινερ, εικονικές μηχανές, Podman, KVM, δικτύωση και ασφάλεια - και ας δούμε πώς να τα συνδυάσουμε για να επιτύχουμε πραγματικά ασφαλή και πρακτική εικονικοποίηση.

Κλασική εικονικοποίηση με KVM και εικονικές μηχανές

Η βάση ολόκληρης αυτής της ρύθμισης παραμένει η πλήρης εικονικοποίηση λειτουργικών συστημάτων χρησιμοποιώντας hypervisors όπως KVM, Xen ή ESXi . Εδώ, το φυσικό υλικό εκτελεί έναν hypervisor που είναι υπεύθυνος για τον "διαχωρισμό" του μηχανήματος σε πολλά ανεξάρτητα εικονικά μηχανήματα.

Σε αυτό το μοντέλο, κάθε εικονική μηχανή εκκινεί τον δικό της πυρήνα και λειτουργικό σύστημα guest , εντελώς ξεχωριστά από τον κεντρικό υπολογιστή. Ο υπερεπόπτης (για παράδειγμα, το KVM, ενσωματωμένο στον πυρήνα του Linux) λειτουργεί ως gatekeeper μεταξύ του υλικού και των εικονικών μηχανών και είναι υπεύθυνος για την ισχυρή απομόνωση μεταξύ τους.

Γενικά μιλάμε για δύο τύπους υπερεπόπτων: τους υπερεπόπτες Τύπου 1 ή bare metal, οι οποίοι εκτελούνται απευθείας στο υλικό, και τους υπερεπόπτες Τύπου 2, οι οποίοι φιλοξενούνται πάνω σε ένα υπάρχον λειτουργικό σύστημα. Το VirtualBox ή το VMware Workstation θα ήταν Τύπου 2 , ενώ ένα KVM που διαχειρίζεται η libvirt σε έναν διακομιστή Linux είναι πιο κοντά σε ένα σενάριο Τύπου 1, παρόλο που μοιράζεται χώρο με τον ίδιο τον κεντρικό υπολογιστή.

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

Για τη διαχείριση αυτών των εικονικοποιημένων πλατφορμών στο GNU/Linux, το libvirt χρησιμοποιείται σχεδόν πάντα ως API ενορχήστρωσης , επιπλέον του οποίου υποστηρίζονται γραφικά εργαλεία και εργαλεία γραμμής εντολών, ή μεγαλύτερα έργα όπως το OpenStack, το οποίο δημιουργεί ολοκληρωμένα clouds συνδυάζοντας VM, bare metal και containers.

Απαιτήσεις υλικού και συνηθισμένα προβλήματα με το KVM

Πριν εκτελέσετε KVM ή χρησιμοποιήσετε λύσεις που εξαρτώνται από αυτό (όπως ορισμένες διαμορφώσεις Docker Desktop ή micro-VM), πρέπει να βεβαιωθείτε ότι ο επεξεργαστής υποστηρίζει εικονικοποίηση υλικού (VT-x σε Intel ή SVM/AMD-V σε AMD) και ότι είναι ενεργοποιημένη στο BIOS/UEFI.

Στο Linux, έχουμε έναν γρήγορο έλεγχο: εάν η εντολή `grep -E 'svm|vmx' /proc/cpuinfo` δεν επιστρέψει τίποτα ή η επιλογή εξακολουθεί να είναι απενεργοποιημένη στο firmware, το KVM δεν θα λειτουργήσει. Επιπλέον, σε σενάρια όπου θα εκτελούμε εικονικές μηχανές μέσα σε μια άλλη εικονική μηχανή (nested virtualization), ο υπερεπόπτης ανώτατου επιπέδου πρέπει να εκθέσει ρητά αυτές τις επεκτάσεις στον επισκέπτη.

Όταν κάτι πάει στραβά, εμφανίζονται τυπικά μηνύματα, όπως το περίφημο αναδυόμενο παράθυρο Docker Desktop στο RHEL 9 μέσα στο VirtualBox: "Το KVM δεν είναι ενεργοποιημένο στον κεντρικό υπολογιστή ." Το πρόβλημα εδώ δεν είναι απευθείας με το Docker ή το RHEL, αλλά μάλλον ότι η εικονική μηχανή VirtualBox δεν λαμβάνει τις απαραίτητες επεκτάσεις εικονικοποίησης για να εκτελέσει το KVM μέσα σε αυτήν.

Εντολές όπως `modprobe kvm` ή `modprobe kvm_amd / kvm_intel` θα πρέπει να φορτώνουν τις μονάδες του πυρήνα χωρίς μηνύματα σφάλματος. Εάν η εντολή `dmesg` δεν εμφανίζει τίποτα σχετικό ή η εντολή `lsmod | grep kvm` εμφανίζει μόνο ένα απλό `kvm` και `irqbypass` και λείπουν οι μονάδες που αφορούν την CPU, είναι πολύ πιθανό η εικονικοποίηση υλικού να μην εκτίθεται στο σύστημα guest ή να είναι απενεργοποιημένη στο firmware.

Σε αυτά τα σενάρια, ακόμη και αν όλες οι πιθανές λειτουργίες είναι ενεργοποιημένες στον επισκέπτη, εάν το VirtualBox δεν προσφέρει nested virtualization ή έχει εσφαλμένα ρυθμιστεί, το KVM απλά δεν θα λειτουργήσει . Η λύση περιλαμβάνει τον έλεγχο της διαμόρφωσης του κεντρικού υπολογιστή hypervisor (VirtualBox, VMware, κ.λπ.) και την ενεργοποίηση της nested virtualization, εάν είναι διαθέσιμη.

Δοχεία: ελαφριά εικονικοποίηση σε επίπεδο λειτουργικού συστήματος

Σε αντίθεση με τις παραδοσιακές εικονικές μηχανές (VM), τα κοντέινερ προσφέρουν μια διαφορετική προσέγγιση: δεν μιμούνται όλο το υλικό, αλλά επαναχρησιμοποιούν τον πυρήνα του κεντρικού υπολογιστή και απομονώνουν διεργασίες και πόρους χρησιμοποιώντας συναρτήσεις του πυρήνα του Linux.

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

Τα κοντέινερ προσφέρουν απόδοση σχεδόν εγγενή επειδή δεν εμπλέκεται δεύτερος πυρήνας και δεν υπάρχει πλήρης εξομοίωση υλικού . Η επιβάρυνση είναι ελάχιστη: αρκετή για την προσάρτηση χώρων ονομάτων, τον περιορισμό πόρων με cgroups και την επιβολή πολιτικών ασφαλείας (seccomp, AppArmor, SELinux, κ.λπ.).

Ωστόσο, αυτός ο σχεδιασμός έχει μια σημαντική συνέπεια: όλα τα workloads μοιράζονται τον ίδιο φυσικό πυρήνα . Ένα σοβαρό κενό ασφαλείας σε αυτόν τον πυρήνα μπορεί ξαφνικά να γίνει ένα πιθανό διάνυσμα διαφυγής για όλα τα containers που εκτελούνται σε αυτόν τον κόμβο.

Γι' αυτό λέγεται συχνά ότι η απομόνωση των κοντέινερ δεν είναι «απόλυτη» όπως αυτή μιας εικονικής μηχανής . Εάν κάποιος καταφέρει να εκμεταλλευτεί ένα κρίσιμο σφάλμα του πυρήνα, οι χώροι ονομάτων παύουν να αποτελούν αποτελεσματικό εμπόδιο και τα όρια μεταξύ κοντέινερ και κεντρικών υπολογιστών μπορούν να παραβιαστούν.

Χώροι ονομάτων και ομάδες c: η βάση της απομόνωσης κοντέινερ

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

Οι χώροι ονομάτων απομονώνουν στοιχεία όπως PID, δίκτυο, σημεία προσάρτησης, IPC, όνομα κεντρικού υπολογιστή (UTS) και χρήστες . Με αυτόν τον τρόπο, μια διεργασία "βλέπει" μόνο τις διεργασίες, τις διεπαφές δικτύου, το σύστημα αρχείων και το όνομα κεντρικού υπολογιστή του δικού της χώρου ονομάτων, δίνοντάς της την αίσθηση ότι βρίσκεται σε διαφορετικό σύστημα.

Από την πλευρά τους, οι ομάδες c σάς επιτρέπουν να καθορίσετε πόση CPU, μνήμη, είσοδο/έξοδο δίσκου, αριθμό διεργασιών κ.λπ. μπορεί να καταναλώσει ένα κοντέινερ . Αυτό αποτρέπει την υπερφόρτωση ολόκληρου του κεντρικού υπολογιστή από ανεξέλεγκτο φορτίο, κάτι που είναι απαραίτητο κατά την κοινή χρήση κόμβων μεταξύ ομάδων ή έργων.

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

Ο λογικός τρόπος για να σκληρύνετε το περιβάλλον είναι να συνδυάσετε τα φίλτρα syscall με seccomp, πολιτικές MAC (AppArmor ή SELinux) και μια δραστική μείωση των δυνατοτήτων των διεργασιών, ιδανικά μαζί με χώρους ονομάτων χρηστών και λειτουργία rootless για την ελαχιστοποίηση της ζημιάς σε περίπτωση που κάποιος καταφέρει να ξεφύγει από το container.

Απειλές ασφαλείας σε πλατφόρμες κοντέινερ

Σε μια πραγματική πλατφόρμα κοντέινερ, η επιφάνεια επίθεσης κατανέμεται σε πολλά επίπεδα: τον πυρήνα και τον χρόνο εκτέλεσης (runc, containerd, CRI-O), την αλυσίδα εφοδιασμού εικόνων, τη διαμόρφωση κοντέινερ/ορχηστρωτή και την υποκείμενη υποδομή (cloud, αποθήκευση, IAM, δίκτυο).

Συνήθεις φορείς επίθεσης περιλαμβάνουν ευπάθειες λογισμικού στον πυρήνα ή στο περιβάλλον εκτέλεσης του κοντέινερ, χρήση μη ασφαλών ή μη συντηρούμενων εικόνων, σφάλματα διαμόρφωσης στο Kubernetes ή το Docker (προνομιούχα κοντέινερ, επικίνδυνες προσαρτήσεις κεντρικού υπολογιστή, υπερβολικά ανοιχτές λειτουργίες δικτύου) και κενά ασφαλείας σε μητρώα ή αγωγούς CI/CD.

Σε πολλά περιστατικά πραγματικού κόσμου, δεν υπάρχει ένα μόνο «μαγικό σφάλμα», αλλά μάλλον ένας συνδυασμός γνωστής ευπάθειας συν χαλαρή διαμόρφωση : κοντέινερ που εκτελούνται ως root, χρήση της σημαίας --privileged, τοποθέτηση του συστήματος αρχείων κεντρικού υπολογιστή εντός του κοντέινερ και απουσία seccomp ή MAC.

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

Επομένως, στην παραγωγή δεν είναι προαιρετικό: πρέπει να σαρώσετε εικόνες για ευπάθειες με εργαλεία όπως Trivy, Clair ή Grype , να ελέγξετε ποια μητρώα χρησιμοποιούνται (Harbor, Quay, GHCR με πολιτικές) και να υπογράψετε/επαληθεύσετε τις εικόνες πριν τις αναπτύξετε σε ένα σύμπλεγμα.

Docker εναντίον Podman: Επιπτώσεις στο μοντέλο απειλής

Στον κόσμο των κοντέινερ εφαρμογών, το Docker και το Podman καλύπτουν παρόμοιες λειτουργίες, αλλά η αρχιτεκτονική τους διαφέρει σημαντικά και αυτό αλλάζει το μοντέλο ασφαλείας με το οποίο εργαζόμαστε σε έναν κεντρικό υπολογιστή.

Το Docker, στην κλασική λειτουργία rootful, βασίζεται σε έναν κεντρικό δαίμονα (dockerd) που εκτελείται ως root . Το CLI επικοινωνεί με αυτόν τον δαίμονα μέσω του /var/run/docker.sock ή μέσω TCP, και αυτή η προνομιακή διαδικασία δημιουργεί και καταστρέφει κοντέινερ, διαχειρίζεται εικόνες, δίκτυα και τόμους και αλληλεπιδρά με μητρώα.

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

Το Podman, από την άλλη πλευρά, γεννήθηκε με την ιδέα να είναι μια μηχανή κοντέινερ χωρίς δαίμονες, όσο το δυνατόν πιο «εγγενής» στο Linux . Δεν υπάρχει μόνιμη κεντρική διεργασία. Τα κοντέινερ ελέγχονται από τον χρήστη ή από το systemd, και η ενσωμάτωση με το τελευταίο επιτρέπει τον έλεγχο των κοντέινερ μέσω μονάδων εξυπηρέτησης.

Αυτή η προσέγγιση ευθυγραμμίζεται καλύτερα με το μοντέλο του Unix που λέει ότι «κάθε διεργασία ανήκει στον χρήστη που την εκκινεί» και αποφεύγει την εξάρτηση από έναν δαίμονα υψηλών δικαιωμάτων . Επιπλέον, το Podman προσφέρει συμβατότητα με τις εντολές του Docker, απλοποιώντας τη μετεγκατάσταση (μπορείτε ακόμη και να χρησιμοποιήσετε ψευδώνυμο `docker=podman` σε περιβάλλοντα όπου δεν θέλετε να εγκαταστήσετε το Docker CE).

Λειτουργία χωρίς ρίζα και χώροι ονομάτων χρηστών

Μία από τις σημαντικότερες πρακτικές εξελίξεις στη μείωση του αντίκτυπου μιας πιθανής διαφυγής από κοντέινερ είναι η λειτουργία χωρίς root σε συνδυασμό με τους χώρους ονομάτων χρηστών . Το ερώτημα που στοχεύει να απαντήσει αυτό είναι: "Τι συμβαίνει εάν το κοντέινερ διαφύγει;"

Οι χώροι ονομάτων χρηστών σάς επιτρέπουν να ανακατατάξετε το UID 0 του κοντέινερ σε ένα μη προνομιούχο UID στον κεντρικό υπολογιστή . Με άλλα λόγια, μέσα στο κοντέινερ η εφαρμογή πιστεύει ότι είναι ο root, αλλά από την οπτική γωνία του κεντρικού υπολογιστή, αυτή η διεργασία είναι στην πραγματικότητα ένας κανονικός χρήστης με ένα εκχωρημένο εύρος subuid/subgid.

Με αυτόν τον τρόπο, ακόμη και αν ένας εισβολέας αποκτήσει δικαιώματα root μέσα στο container και καταφέρει να συνδέσει έναν πυρήνα ή ένα runtime exploit, κατά την επιστροφή του στον κεντρικό υπολογιστή το κάνει ως χρήστης χωρίς δικαιώματα . Δεν μπορεί να αντικαταστήσει τα root binary αρχεία, να προσαρτήσει ευαίσθητα συστήματα αρχείων ή να χειριστεί συσκευές όπου δεν έχει τα απαραίτητα δικαιώματα.

Το Podman σχεδιάστηκε εξαρχής με γνώμονα αυτό το μοντέλο: rootless containerization από προεπιλογή όποτε είναι δυνατόν , χρήση SELinux/AppArmor και cgroups ακόμη και χωρίς root, και ισχυρή έμφαση στην ελαχιστοποίηση των δομικών προνομίων.

Το Docker προσφέρει πλέον και μια πραγματική λειτουργία rootless , όπου το dockerd και τα κοντέινερ βρίσκονται μέσα σε έναν χώρο ονομάτων χρήστη, σε αντίθεση με το παλαιότερο userns-remap όπου ο daemon παρέμενε root. Από άποψη ασφάλειας, αυτό εμποδίζει μια εκμετάλλευση κατά του dockerd να παραχωρήσει αυτόματη πρόσβαση root στον κεντρικό υπολογιστή.

Δίκτυα κοντέινερ με Podman: διεπαφές γέφυρας, κεντρικού υπολογιστή, macvlan και rootless

Ένα άλλο σημαντικό στοιχείο για την ασφάλεια και την πρακτική λειτουργία είναι το επίπεδο δικτύου κοντέινερ . Το Podman προσφέρει διάφορους μηχανισμούς για την παροχή συνδεσιμότητας, με ιδιαίτερη προσοχή σε σενάρια χωρίς root.

Το Podman 4 εισήγαγε το netavark, ένα πρόγραμμα οδήγησης δικτύου που ακολουθεί το μοντέλο CNI για να παρέχει σε κοντέινερ διευθύνσεις IP σε δίκτυα γέφυρας, macvlans κ.λπ. Με το netavark, τα κοντέινερ rootful συνήθως συνδέονται από προεπιλογή σε ένα δίκτυο που ονομάζεται "podman" που σχετίζεται με μια γέφυρα Linux (podman0) στον κεντρικό υπολογιστή, με διεύθυνση 10.88.0.0/16.

Αυτό το προεπιλεγμένο δίκτυο γέφυρας παρέχει βασική συνδεσιμότητα στο διαδίκτυο μέσω κανόνων SNAT και σας επιτρέπει να εκθέτετε θύρες κοντέινερ στον κεντρικό υπολογιστή χρησιμοποιώντας την εντολή `-po --publish`, η οποία δημιουργεί κανόνες DNAT σε iptables/nftables. Για συμβατότητα με το Docker, αυτό το δίκτυο δεν εκτελεί εσωτερικό διακομιστή DNS.

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

Σε πιο προηγμένα περιβάλλοντα, είναι δυνατή η χρήση δικτύων macvlan ή ipvlan για την απευθείας σύνδεση κοντέινερ στο φυσικό δίκτυο του κεντρικού υπολογιστή. Το Macvlan επιτρέπει στα κοντέινερ να επικοινωνούν μεταξύ τους, ενώ το ipvlan τείνει να τα απομονώνει περισσότερο. Αυτές είναι χρήσιμες επιλογές σε αναπτύξεις όπου κάθε κοντέινερ πρέπει να θεωρείται ως πραγματικός κεντρικός υπολογιστής από το υπόλοιπο δίκτυο.

Δίκτυα χωρίς ρίζες: slirp4netns και pasta

Όταν ο χρήστης δεν είναι root, τα πράγματα περιπλέκονται: ένας χρήστης χωρίς δικαιώματα δεν μπορεί να τροποποιήσει ελεύθερα τον παγκόσμιο χώρο ονομάτων δικτύου ή να δημιουργήσει αυθαίρετες διεπαφές, επομένως το Podman πρέπει να καταφύγει σε λύσεις χώρου χρήστη για να παρέχει συνδεσιμότητα.

Εδώ έρχεται το slirp4netns , ο κλασικός μηχανισμός που χρησιμοποιείται από το Podman rootless . Αυτό το έργο δημιουργεί ένα απομονωμένο περιβάλλον δικτύου μέσα στο κοντέινερ και χρησιμοποιεί τη μονάδα slirp του πυρήνα για να εκτελέσει μετάφραση διευθύνσεων (NAT) και να επιτρέψει στο κοντέινερ να έχει πρόσβαση στο διαδίκτυο μέσω του δικτύου του κεντρικού υπολογιστή.

Στην πράξη, το slirp4netns δημιουργεί μια διεπαφή TAP εντός του χώρου ονομάτων δικτύου του κοντέινερ (για παράδειγμα, tap0 με IP 10.0.2.100 και πύλη 10.0.2.2) και δρομολογεί την κυκλοφορία μέσω μιας στοίβας TCP/IP που έχει υλοποιηθεί στον χώρο χρήστη. Είναι λειτουργικό, αλλά προσθέτει κάποια επιβάρυνση και ορισμένους περιορισμούς.

Ένας από αυτούς τους περιορισμούς είναι ότι οι χρήστες χωρίς δικαιώματα δεν μπορούν να χρησιμοποιήσουν θύρες κάτω των 1024. Η παράμετρος sysctl net.ipv4.ip_unprivileged_port_start σηματοδοτεί από ποια θύρα θεωρούνται "χωρίς δικαιώματα" (από προεπιλογή, 1024), αν και αυτό μπορεί να προσαρμοστεί προσεκτικά εάν το μοντέλο ασφαλείας το επιτρέπει.

Στο Podman 5, το slirp4netns αντικαθίσταται από το pasta ως ο προεπιλεγμένος μηχανισμός rootless . Το Pasta λειτουργεί επίσης εξ ολοκλήρου στον χώρο χρήστη, αλλά χάρη στη διεπαφή tap και στις τεχνικές μηδενικού αντιγράφου, επιτυγχάνει απόδοση δικτύου σχεδόν εγγενούς επιπέδου, μειώνοντας τον αντίκτυπο στην καθυστέρηση και την απόδοση σε σύγκριση με το slirp4netns.

Γεφύρωση δικτύων και δικτύων κεντρικών υπολογιστών σε κοντέινερ χωρίς rootless

Ακόμα και όταν εργαζόμαστε σε λειτουργία χωρίς root, μπορούμε να συνδέσουμε κοντέινερ χωρίς root στο προεπιλεγμένο δίκτυο γέφυρας "podman" χρησιμοποιώντας το `--network=podman`. Αυτό εκμεταλλεύεται τις δυνατότητες του netavark και αντιστοιχίζει θύρες στον κεντρικό υπολογιστή με το `-p`, όπως ακριβώς και στη λειτουργία rootful.

Είναι επίσης δυνατή η δημιουργία δικτύων γεφυρών που ορίζονται από τον χρήστη σε περιβάλλοντα χωρίς root . Σε αυτήν την περίπτωση, οι γέφυρες και οι συσχετισμένες συσκευές δεν δημιουργούνται στον χώρο ονομάτων παγκόσμιου δικτύου του κεντρικού υπολογιστή, αλλά στον χώρο ονομάτων του χρήστη, επομένως αυτές οι διεπαφές δεν θα είναι ορατές από τον κεντρικό υπολογιστή με μια απλή εντολή `sudo ip a`.

Για να ελέγξει αυτές τις γέφυρες χωρίς root, το Podman προσφέρει την εντολή `podman unshare --rootless-netns` , η οποία ανοίγει ένα κέλυφος στον χώρο ονομάτων δικτύου του χρήστη. Από εκεί, μπορούν να παρατηρηθούν οι εσωτερικές γέφυρες και να επαληθευτεί η άμεση συνδεσιμότητα με τα κοντέινερ.

Αυτή η απομόνωση έχει ένα περίεργο αποτέλεσμα: Ενδέχεται να μην υπάρχει άμεση σύνδεση από τον κεντρικό υπολογιστή στις διευθύνσεις IP αυτών των κοντέινερ χωρίς root.αλλά λειτουργεί με θύρες που αντιστοιχίζονται στη διεύθυνση IP του κεντρικού υπολογιστή, οι οποίες λειτουργούν ως σημείο εισόδου στην υπηρεσία.
Για την επικοινωνία μεταξύ κοντέινερ, ο διακομιστής DNS που είναι ενσωματωμένος στο δίκτυο γέφυρας που ορίζεται από τον χρήστη τους επιτρέπει να μιλούν με το όνομά τους, γεγονός που απλοποιεί σημαντικά τη διαμόρφωση των κατανεμημένων εφαρμογών.

Στο άλλο άκρο βρίσκεται το δίκτυο κεντρικού υπολογιστή (--network=host) , όπου το κοντέινερ μοιράζεται τη στοίβα δικτύου με τον κεντρικό υπολογιστή χωρίς τη δική του διεύθυνση IP. Σε αυτήν τη λειτουργία, εάν ένα κοντέινερ χωρίς root εκκινήσει έναν διακομιστή στη θύρα 8080/tcp, η υπηρεσία θα είναι άμεσα διαθέσιμη στη θύρα 8080 του κεντρικού υπολογιστή, εξοικονομώντας έτσι την αντιστοίχιση θυρών αλλά μειώνοντας την απομόνωση.

Podman Desktop, εργαλεία απεικόνισης και τοπική ενορχήστρωση

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

Οι εικόνες λαμβάνονται χρησιμοποιώντας την εντολή `podman pull`, η οποία λαμβάνεται από τα μητρώα που ορίζονται στο `/etc/containers/registries.conf` . Εάν η εικόνα έχει καθοριστεί χωρίς όνομα μητρώου, το Podman επιχειρεί να την εντοπίσει εντός της διαμορφωμένης σειράς μητρώου, χρησιμοποιώντας την ετικέτα `latest` από προεπιλογή.

Εκτός από το Podman CLI, μπορούμε να χρησιμοποιήσουμε το skopeo ως ένα ειδικό εργαλείο για τη διαχείριση, την επιθεώρηση και την αντιγραφή εικόνων μεταξύ μητρώων και τοπικών αποθετηρίων. Εντολές όπως αντιγραφή, διαγραφή και συγχρονισμός μας επιτρέπουν να αυτοματοποιήσουμε τον συγχρονισμό μεταξύ αποθετηρίων, να επισημάνουμε εικόνες για συλλογή απορριμμάτων και να μετακινήσουμε αντικείμενα μεταξύ περιβαλλόντων.

Μόλις ολοκληρωθεί η λήψη της εικόνας, η εντολή `podman run` σάς επιτρέπει να ξεκινήσετε κοντέινερ καθορίζοντας τη μεταφορά και τη διαδρομή (από προεπιλογή, μεταφορά Docker και αναζήτηση στο διαμορφωμένο μητρώο). Οι συνήθεις επιλογές (-d, -p, --name, --pod, κ.λπ.) καλύπτουν τόσο σενάρια εργαστηρίου όσο και πιο σοβαρές αναπτύξεις.

Η καθημερινή διαχείριση ολοκληρώνεται με την εντολή `podman ps` για την καταχώριση των containers, την εντολή `podman stop/start` για τη διακοπή ή την έναρξη υπαρχουσών στιγμιότυπων και την εντολή `podman rm` για την αφαίρεση των containers που έχουν σταματήσει . Εάν ένα container έχει τροποποιηθεί και θέλουμε να το μετατρέψουμε σε νέα εικόνα, η εντολή `podman commit` αποθηκεύει αυτές τις αλλαγές με νέο όνομα.

Pods και προηγμένα μοντέλα εκτέλεσης με Podman

Εμπνευσμένο από το Kubernetes, το Podman σάς επιτρέπει να ομαδοποιείτε κοντέινερ σε pods που μοιράζονται την ίδια στοίβα δικτύου και ορισμένους πόρους . Είναι ένα τέλειο μοτίβο για πράγματα όπως μια βάση δεδομένων και ο πελάτης της ή πολλαπλές μικρουπηρεσίες που πρέπει να επικοινωνούν με χαμηλή καθυστέρηση.

Η εντολή `podman pod create` δημιουργεί ένα νέο pod και επιστρέφει το αναγνωριστικό του, αλλά από προεπιλογή το pod παραμένει σταματημένο μέχρι να ξεκινήσει ένα συσχετισμένο κοντέινερ ή να ξεκινήσει ρητά με το `podman pod start`.

Για να δείτε ποια pod υπάρχουν στο σύστημα, χρησιμοποιήστε την εντολή `podman pod ls` , η οποία θα εμφανίσει επίσης το κοντέινερ INFRA που σχετίζεται με το καθένα. Αυτό το ειδικό κοντέινερ διατηρεί το δίκτυο και άλλους κοινόχρηστους πόρους του pod σε λειτουργία, επομένως ο αριθμός των κοντέινερ δεν είναι ποτέ μηδέν.

Το Podman προσφέρει συγκεκριμένες εντολές για την εκκίνηση, τη διακοπή ή την επανεκκίνηση ολόκληρων pod (podman pod start/stop/restart) , αλλά μπορούμε επίσης να ενεργήσουμε μόνο σε ένα συγκεκριμένο κοντέινερ μέσα στο pod χωρίς να τροποποιήσουμε τα υπόλοιπα, διατηρώντας την απομόνωση της διεργασίας σε επίπεδο εφαρμογής.

Για να προσθέσετε περισσότερα κοντέινερ σε μια υπάρχουσα ομάδα, χρησιμοποιήστε την εντολή `podman run --pod POD_NAME` , ακολουθώντας την ίδια σύνταξη όπως και για μεμονωμένα κοντέινερ. Δεν μπορείτε να αφαιρέσετε ένα κοντέινερ από μια ομάδα χωρίς να το καταστρέψετε, καθώς η συμμετοχή σε ομάδα συνδέεται με τον κύκλο ζωής του.

Η παρακολούθηση ολοκληρώνεται με το podman ps –pod ή με συγκεκριμένες εντολές για την παρακολούθηση των διεργασιών όλων των κοντέινερ σε όλα τα pods , προσδιορίζοντας γρήγορα τι ανήκει σε ποια ομάδα και πώς κατανέμονται οι υπηρεσίες.

Κοντέινερ, LXC και εικονικοποίηση εφαρμογών

Παρόλο που τα Docker και Podman κυριαρχούν στη συζήτηση, δεν είναι οι μόνες επιλογές containerization στο GNU/Linux . Λύσεις όπως τα LXC/LXD, systemd-nspawn και Kata Containers αντιμετωπίζουν το πρόβλημα από ελαφρώς διαφορετικές οπτικές γωνίες.

Το LXC παρέχει πολύ ελαφριά κοντέινερ συστήματος, με το δικό τους όνομα κεντρικού υπολογιστή, διεύθυνση IP, σύστημα αρχείων και πλήρες σύστημα init . Σε συνδυασμό με το LXD, το οποίο λειτουργεί ως hypervisor για κοντέινερ και εικονικές μηχανές, προσφέρει μια εμπειρία που πλησιάζει πολύ την ύπαρξη πολλαπλών ελαφριών μηχανημάτων με σχεδόν μηδενική απόδοση.

Ενώ τα Docker/Podman επικεντρώνονται σε κοντέινερ εφαρμογών συμβατά με OCI , το LXC ξεχωρίζει όταν απαιτούνται μόνιμα περιβάλλοντα με πολλαπλές υπηρεσίες και διεργασίες, συμπεριφερόμενο σαν εικονική μηχανή αλλά με λιγότερη επιβάρυνση και πολύ φυσική ενσωμάτωση με τον πυρήνα του Linux.

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

Παράλληλα, τεχνολογίες που προσανατολίζονται σε μικρο-ΕΜ και ενισχυμένη απομόνωση έχουν επίσης κερδίσει έδαφος, όπως το Kata Containers , το οποίο εκκινεί κάθε pod μέσα σε μια μικρή εικονική μηχανή με τον δικό της πυρήνα, ή το gVisor, το οποίο εισάγει ένα "kernel sandbox" γραμμένο σε Go μεταξύ της εφαρμογής και του Linux. Και οι δύο μειώνουν την εξάρτηση από τον κοινόχρηστο πυρήνα και προσεγγίζουν το μοντέλο ασφαλείας των ΕΜ, διατηρώντας παράλληλα την φιλικότητα προς τον χρήστη των containers.

Βέλτιστες πρακτικές για την ενίσχυση των Docker και Podman

Με όλα τα παραπάνω, η λογική προσέγγιση για μια ισχυρή πλατφόρμα κοντέινερ είναι η εργασία σε επίπεδα: τμηματοποίηση με χώρους ονομάτων/cgroups, πολιτικές φιλτραρίσματος με seccomp και MAC και περιορισμός δομικών προνομίων μέσω λειτουργίας χωρίς root.

Στην πράξη, συνιστάται να υιοθετείται η τυπική πρακτική της εκτέλεσης κοντέινερ σε λειτουργία χωρίς root όποτε είναι δυνατόν , ειδικά σε περιβάλλοντα πολλαπλών μισθωτών ή εντός κοινόχρηστων cloud. Το Podman διευκολύνει αυτό από προεπιλογή και το Docker rootless καλύπτει την ίδια φιλοσοφία όταν απαιτείται συμβατότητα.

Ο πυρήνας του κεντρικού υπολογιστή πρέπει να διατηρείται ενημερωμένος με ενημερώσεις ασφαλείας . Ευπάθειες όπως το Dirty COW, το Dirty Pipe και άλλες αντιμετωπίζονται με ενημερώσεις που πρέπει να εφαρμόζονται σχετικά γρήγορα, αν δεν θέλουμε να αφήσουμε ανοιχτή την πόρτα για διαφυγές από κοντέινερ.

Ένα άλλο εξαιρετικά αποτελεσματικό μέτρο είναι η χρήση αμετάβλητων, προσανατολισμένων σε κοντέινερ διανομών, όπως το openSUSE MicroOS ή το Flatcar Linux . Το σύστημα root και atomic update που διαθέτουν, το οποίο είναι μόνο για ανάγνωση, μειώνει σημαντικά την επιφάνεια επίθεσης και διευκολύνει την επαναφορά των δεδομένων σε περίπτωση που κάτι πάει στραβά μετά από μια ενημέρωση κώδικα.

Όσον αφορά τη διαμόρφωση: δεν υπάρχουν προνομιούχα κοντέινερ στην παραγωγή εκτός από εξαιρετικά ελεγχόμενες περιπτώσεις , μην εκτελείτε εφαρμογές ως root μέσα στο κοντέινερ, χρησιμοποιείτε συστήματα αρχείων μόνο για ανάγνωση όποτε είναι δυνατόν και περιορίζετε τις δυνατότητες στο ελάχιστο. Τα προφίλ SELinux/AppArmor και seccomp που είναι προσαρμοσμένα στις πραγματικές κλήσεις της εφαρμογής είναι πρακτικά υποχρεωτικά.

Τέλος, δεν πρέπει να ξεχνάμε την πτυχή της παρακολούθησης χρόνου εκτέλεσης . Εργαλεία όπως το Falco, το Sysdig Secure ή το Aqua βοηθούν στην ανίχνευση ανωμαλιών, προσπαθειών διαφυγής (όπως ασυνήθιστη πρόσβαση στο /proc ή /sys), άτυπης κυκλοφορίας δικτύου ή ύποπτων εντολών, παρέχοντας χρόνο αντίδρασης πριν η επίθεση τεθεί σε ισχύ.

Συνδυάζοντας την κλασική εικονικοποίηση με το KVM, τα κοντέινερ που διαχειρίζεται το Podman (κατά προτίμηση σε λειτουργία rootless), τα καλά τμηματοποιημένα δίκτυα και τις καλές πρακτικές θωράκισης, μπορεί να δημιουργηθεί μια εξαιρετικά ευέλικτη και αρκετά ασφαλής πλατφόρμα εικονικοποίησης. Η κατανόηση ότι ο κοινόχρηστος πυρήνας είναι το πιο κρίσιμο σημείο, η εξάρτηση από εικονικές μηχανές (VM) ή μικρο-VM όταν το απαιτεί ο κίνδυνος ή η κανονιστική συμμόρφωση, και η προσεκτική διαχείριση της αλυσίδας εφοδιασμού εικόνων κάνει τη διαφορά μεταξύ ενός εργαστηριακού περιβάλλοντος και μιας υποδομής έτοιμης για παραγωγή.