Docker ή Podman: η ασφάλεια rootless δεν κρίνεται από την ταχύτητα

Για εγκατάσταση σε Linux, η επιλογή ανάμεσα σε Docker και Podman κρίνεται πρώτα από το μοντέλο προνομίων και τις εξαρτήσεις της υπηρεσίας. Η ταχύτητα ενός υπολογιστικού τεστ δεν μετρά την ασφάλεια rootless. Το Docker μπορεί να λειτουργήσει χωρίς προνόμια root τόσο για τον daemon όσο και για τα containers, όπως ορίζει η τεκμηρίωση rootless του Docker.

Το Podman ταιριάζει όταν θέλετε τοπική διαχείριση containers χωρίς μόνιμο daemon και υπηρεσίες συνδεδεμένες με τον χρήστη του Linux. Το Docker παραμένει πρακτική επιλογή όταν Compose αρχεία και αυτοματισμοί εξαρτώνται ήδη από το Docker API. Η τεκμηρίωση του Podman περιγράφει οικείο CLI και εκτέλεση από μη προνομιούχο χρήστη, αλλά η ομοιότητα των εντολών δεν μεταφέρει αυτόματα δίκτυα, δεδομένα και υπηρεσίες.

Rootless: ίδια επιδίωξη, διαφορετική αρχιτεκτονική

Στο Docker, το CLI επικοινωνεί με daemon που διαχειρίζεται τους πόρους των containers. Με rootless λειτουργία, αυτή η σχέση πελάτη και daemon διατηρείται, αλλά ο daemon και τα containers εκτελούνται μέσα σε χώρο ονομάτων χρήστη, χωρίς δικαιώματα root στον host. Αυτό διαφέρει από το userns-remap, όπου τα containers χρησιμοποιούν αντιστοίχιση χρηστών αλλά ο daemon εξακολουθεί να τρέχει με δικαιώματα root.

Για τη rootless εγκατάσταση του Docker χρειάζονται τα εργαλεία newuidmap και newgidmap και κατάλληλα εύρη subordinate UID και GID στα /etc/subuid και /etc/subgid. Το Podman χρησιμοποιεί επίσης χώρο ονομάτων χρήστη στη rootless λειτουργία και χρειάζεται αντίστοιχη ρύθμιση ταυτοτήτων για τη συνήθη χρήση πολλών UID και GID. Επομένως, η απουσία μόνιμου daemon αλλάζει την οργάνωση της διαχείρισης· δεν παρακάμπτει τις απαιτήσεις του Linux για τα δικαιώματα χρηστών.

Το rootless περιορίζει τα προνόμια των διεργασιών του engine στον host, όχι τις δυνατότητες που παραχωρείτε στην εφαρμογή. Ένα bind mount εξακολουθεί να εκθέτει τα αρχεία στα οποία έχει πρόσβαση ο αντίστοιχος χρήστης του host. Η αντιστοίχιση ταυτοτήτων μπορεί επίσης να κάνει ένα αρχείο εγγράψιμο μέσα στο container αλλά απρόσιτο σε άλλη διεργασία του host, ή το αντίστροφο. Για υπηρεσίες με μόνιμα δεδομένα, η ιδιοκτησία των αρχείων είναι μέρος της απόφασης ασφαλείας και λειτουργίας.

Το οικείο CLI δεν ισοδυναμεί με ίδια εγκατάσταση

Οι εντολές για λήψη image, εκκίνηση και επιθεώρηση container μοιάζουν αρκετά ώστε πολλά απλά scripts να χρειάζονται μικρές αλλαγές. Ένα script όμως μπορεί να βασίζεται στο Docker socket, σε συγκεκριμένο API ή στον τρόπο που ο daemon αποθηκεύει την κατάστασή του. Σε αυτή την περίπτωση, η αντικατάσταση της λέξης docker με podman αφήνει ανέπαφη την πραγματική εξάρτηση.

Η συμβατότητα των OCI images βοηθά να μεταφερθεί το εκτελέσιμο περιβάλλον της εφαρμογής. Δεν μεταφέρει τα named volumes του υπάρχοντος engine, τις ρυθμίσεις δημοσίευσης θυρών ή τη μέθοδο με την οποία μια υπηρεσία επανέρχεται μετά από επανεκκίνηση του host. Υπάρχει και διαφορά ορατότητας: τα rootless containers ενός χρήστη στο Podman δεν εμφανίζονται αυτόματα στους άλλους χρήστες του συστήματος. Αυτό επηρεάζει τον λογαριασμό από τον οποίο εκτελούνται εργασίες συντήρησης και CI.

Χάρτης μετάβασης για τις εξαρτήσεις της υπηρεσίας

• Compose. Η εντολή podman compose καλεί εξωτερικό Compose provider, όπως docker-compose ή podman-compose, και τον συνδέει με το τοπικό Podman socket. Επομένως, η συμπεριφορά εξαρτάται και από τον provider που είναι εγκατεστημένος. Για ένα υπάρχον compose.yaml έχουν σημασία οι εξαρτήσεις μεταξύ υπηρεσιών, τα δίκτυα, τα mounts και οι επιλογές που χρησιμοποιεί πραγματικά το αρχείο.
• Networking. Στη rootless λειτουργία, η δημοσίευση θυρών και η επικοινωνία μεταξύ υπηρεσιών περνούν από τη δικτύωση του μη προνομιούχου χρήστη. Το Podman αναφέρει το pasta ως απαραίτητο για τη δημιουργία συσκευής δικτύου στην τρέχουσα τεκμηρίωσή του· χωρίς αυτό, τα rootless containers χρειάζεται να χρησιμοποιούν τον χώρο ονομάτων δικτύου του host. Αυτό κάνει τις υποθέσεις για διευθύνσεις, ονόματα και προσβάσιμες θύρες ουσιαστικό σημείο ελέγχου της μετάβασης.
• Volumes και bind mounts. Το νέο image δεν περιέχει τα δεδομένα ενός υπάρχοντος named volume. Για κάθε υπηρεσία πρέπει να ξεχωρίσετε τα δεδομένα που κρατά ο engine από τους καταλόγους που προσαρτώνται από τον host και να διατηρήσετε τη σωστή ιδιοκτησία τους. Αν η αντιστοίχιση UID/GID του rootless χρήστη δεν επιτρέπει εγγραφή, το container μπορεί να ξεκινά κανονικά ενώ η εφαρμογή αποτυγχάνει όταν χρειαστεί να αποθηκεύσει δεδομένα.
• systemd. Το Podman Quadlet παράγει μονάδες systemd από δηλώσεις για containers, δίκτυα και volumes και έχει συγκεκριμένες διαδρομές αναζήτησης για rootless χρήστες. Μια τέτοια δήλωση ανήκει σε διαδρομή μονάδων χρήστη, όπως ~/.config/containers/systemd/. Η προσθήκη User σε μονάδα συστήματος δεν είναι ισοδύναμος τρόπος εκτέλεσης rootless Quadlet. Για υπηρεσίες που πρέπει να επανέρχονται μετά από επανεκκίνηση, μετρά επίσης ο κύκλος ζωής του λογαριασμού χρήστη.
• CI. Ένας runner που εκτελεί μόνο build και δοκιμές containers έχει διαφορετικές εξαρτήσεις από runner που ζητά Docker API socket ή εκτελεί Compose. Η αλλαγή engine απαιτεί να είναι σαφές ποιος χρήστης κατέχει τα images και τα containers, ποιος provider εκτελεί το Compose και πώς καθαρίζονται οι πόροι μετά την εργασία. Ένα επιτυχημένο build μόνο του δεν δείχνει ότι λειτουργούν και οι δοκιμές που χρειάζονται δίκτυο ή volume.

Τι μετρήθηκε στην πράξη

Στη μεταπτυχιακή εργασία του Πανεπιστημίου του Όουλου, οι μετρήσεις Y-Cruncher έδωσαν μέσο χρόνο 134 δευτερολέπτων για native εκτέλεση, Docker και Podman στο συγκεκριμένο laptop και workload. Το τεστ μετρούσε υπολογισμό ψηφίων του π. Η ισότητα αυτού του χρόνου δείχνει ότι, στις συνθήκες της δοκιμής, η επιλογή των δύο container engines δεν άλλαξε ουσιαστικά τον συγκεκριμένο χρόνο υπολογισμού.

Η ίδια εργασία εξέτασε χωριστά τον χρόνο από την εκκίνηση έως τον τερματισμό container και βρήκε διαφορετικά αποτελέσματα για τους δύο engines. Εκεί μεσολαβούσαν εκκίνηση, προσαρτήσεις volumes και τερματισμός, δηλαδή εργασίες διαφορετικές από τον καθαρό υπολογισμό του Y-Cruncher. Καμία από αυτές τις μετρήσεις δεν αποτελεί μέτρο της προστασίας που προσφέρει η rootless ρύθμιση. Ούτε αρκεί για να προβλέψει την απόδοση μιας εφαρμογής που εξαρτάται κυρίως από δίκτυο, δίσκο ή συχνή δημιουργία βραχύβιων containers.

Πότε συμφέρει κάθε επιλογή

Για νέα υπηρεσία Linux που θα ανήκει σε μη προνομιούχο χρήστη και θα λειτουργεί μέσω systemd, το Podman προσφέρει άμεση αρχιτεκτονική διαδρομή, εφόσον οι απαιτήσεις δικτύου και αποθήκευσης ταιριάζουν στη rootless ρύθμιση. Για εγκατάσταση με ώριμα Compose αρχεία, scripts και runners δεμένους με το Docker API, η παραμονή στο Docker μπορεί να κοστίσει λιγότερο σε αλλαγές. Το δικό του rootless mode επιτρέπει τη μείωση των προνομίων του daemon χωρίς ταυτόχρονη αντικατάσταση του engine.

Το ουσιαστικό κόστος μετάβασης βρίσκεται στις εξαρτήσεις γύρω από το container: ποιος χρήστης βλέπει τα δεδομένα, ποιος provider εκτελεί το Compose, πώς φτάνει η κίνηση στην υπηρεσία και ποιος την επανεκκινεί. Όταν αυτά έχουν απλή απάντηση, η αλλαγή engine μπορεί να είναι μικρή. Όταν στηρίζονται σε Docker socket, υπάρχοντα volumes ή ιδιαίτερη δικτύωση, χρειάζονται ξεχωριστό σχέδιο, ανεξάρτητα από το πόσο κοντά βρίσκονται οι χρόνοι ενός benchmark.

Διαβάστε επίσης:

• TikTok: παιδιά ενεργοποίησαν εργαλεία ασφάλειας που δεν λειτουργούσαν
• Pinecone ή Weaviate: η ταχύτητα δεν αρκεί χωρίς κόστος κλιμάκωσης
• LangChain ή LlamaIndex: ο RAG κρίνεται πριν από το μοντέλο