639 lines
70 KiB
TeX
639 lines
70 KiB
TeX
\chapter{Εισαγωγή} \label{introduction}
|
||
|
||
\noindent Παραδοσιακά, όταν ένας χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
|
||
υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
|
||
αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας αποδοχής,
|
||
καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
|
||
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεις δεδομένων
|
||
(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
|
||
κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
|
||
κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
|
||
λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα σημαντικό
|
||
κόστος.
|
||
|
||
Στις αρχές του 2000 ο τρόπος διεξαγωγής της παραπάνω διαδικασίας άλλαξε ριζικά
|
||
όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
|
||
τομέα του ηλεκτρονικού εμπορίου (e-commerce), δημιούργησε την θυγατρική της,
|
||
AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρεσίες
|
||
νεφο-υπολογιστικής και συγκεκριμένα, την EC2 (Elastic Compute Cloud), μια
|
||
υπηρεσία τύπου IaaS (Infrastructure as a Service). Πρόκειται για την πρώτη
|
||
υπηρεσία ενοικίασης υπολογιστικών πόρων προς αξιοποίηση από οργανισμούς και
|
||
επιχειρήσεις προκειμένου να επιταχυνθεί η διαδικασία διάθεσης των δικών τους
|
||
υπηρεσιών. Αυτό το μοντέλο λειτουργίας παρέχει πολλά πλεονεκτήματα, όπως το
|
||
μικρότερο κόστος εκκίνησης διάθεσης υπηρεσιών, η διευκόλυνση κλιμάκωσής τους
|
||
(είτε οριζόντιας όπου μοιράζεται ο φόρτος εργασίας σε παραπάνω διακομιστές είτε
|
||
κάθετης κατά την οποία ένας διακομιστής αναβαθμίζεται με ισχυρότερες
|
||
προδιαγραφές \footfullcite{cloudzeroScalability}) και η απαλλαγή ευθύνης
|
||
σχετικά με την συνεχή λειτουργία του εξοπλισμού στον οποίο στεγάζονται.
|
||
|
||
Λόγω της ευρείας αποδοχής της και των πολλών πλεονεκτημάτων που παρέχει, πολλές
|
||
άλλες εταιρείες, όπως η Google, IBM και Microsoft, άρχισαν να προσφέρουν και
|
||
αυτές υπηρεσίες ιδίου τύπου. Σήμερα, ο μέσος καταναλωτής έχει στην διάθεση του
|
||
μια πληθώρα εταιρειών που προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα
|
||
μερικές από αυτές, όπως η Linode, Vultr και Digital Ocean, προσφέρουν ως την
|
||
κύρια υπηρεσία τους τη δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με
|
||
τη μορφή ενοικίασης εικονικών μηχανών.
|
||
|
||
\section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}
|
||
|
||
Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
|
||
χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
|
||
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη της
|
||
εξαρτάται από 3 βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
|
||
νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
|
||
νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
|
||
που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
|
||
τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους απομακρυσμένους
|
||
(εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον προβεί στην χρήση
|
||
δοχείων. Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες
|
||
οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
|
||
ασφάλεια σύμφωνα με τις ανάγκες του.
|
||
|
||
Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
|
||
πλατφόρμες IaaS, προς διευκόλυνσή του η διαδικασία γίνεται και μέσω γραφικού
|
||
περιβάλλοντος της μορφής Point and Click. Στις εικονικές μηχανές που
|
||
προσφέρονται, τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
|
||
συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
|
||
των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
|
||
MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τρόπο, η διαδικασία
|
||
δημιουργίας εικονικής μηχανής είναι αρκετά εύκολη για τον χρήστη, ο οποίος δεν
|
||
χρειάζεται να έχει ειδικές γνώσεις στο υλικό για να το πετύχει αυτό. Στην
|
||
προκειμένη περίπτωση, ενώ υπήρχε μηδενική δυσκολία για την απόκτηση εικονικής
|
||
μηχανής εξοπλισμένης με λειτουργικό σύστημα και πιθανότατα απαραίτητα προς
|
||
χρήση προγράμματα, η ασφάλειά της δεν είναι πάντοτε εγγυημένη. Πολλά από τα
|
||
προγράμματα που θα χρησιμοποιήσει ο χρήστης δεν παρέχουν εξ αρχής
|
||
ενεργοποιημένες τις παραμέτρους ασφαλείας που μπορεί να υποστηρίζουν διότι δεν
|
||
δύναται να υπάρχει μια ασφαλής ρύθμιση που να καλύπτει όλα τα πιθανά σενάρια
|
||
χρήσης. Επιπλέον, η ρύθμιση των παραμέτρων ασφαλείας είναι μια διαδικασία που
|
||
απαιτεί εξειδικευμένες γνώσεις και είναι αρκετά εύκολο όχι μόνο να παραλειφθεί
|
||
αλλά και να γίνει λανθασμένα λόγω έλλειψης οικειότητας με τα εργαλεία που έχει
|
||
στην διάθεση του ο χρήστης.
|
||
|
||
\clearpage
|
||
|
||
Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
|
||
που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
|
||
ρυθμισμένα εκ τω προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
|
||
όπου υπάρχει τυφλή εμπιστοσύνη προς την ορθότητα των ρυθμίσεων αυτών σε
|
||
συνδυασμό με έλλειψη γνώσης των εργαλείων, ενδέχεται λόγω ανθρώπινου λάθους ή
|
||
στοχευμένα, να μένει ο τελικός χρήστης ευάλωτος σε ρίσκα ασφαλείας, όπως μη
|
||
εξουσιοδοτημένη πρόσβαση, μόλυνση με κακόβουλο λογισμικό και υποκλοπές
|
||
ευαίσθητων προσωπικών δεδομένων. Στην περίπτωση που και ο πάροχος νέφους έχει
|
||
παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
|
||
εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
|
||
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking
|
||
\footfullcite{Hyperjacking} και να αποκτήσει έλεγχο του υπερ-επόπτη με
|
||
αποτέλεσμα να είναι σε θέση να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές
|
||
μηχανές είτε στον (φυσικό) διακομιστή στον οποίο εκτελείται.
|
||
|
||
\section{Εικονικοποίηση και τεχνολογίες υλοποίησης της} \label{virtualizationTechnologiesIntroduction}
|
||
|
||
Η εικονικοποίηση είναι ένας όρος που χρησιμοποιούμε όταν θέλουμε να αναφερθούμε
|
||
στην αναπαράσταση πόρων σε εικονική μορφή με σκοπό την αναδιαμόρφωσή τους ούτως
|
||
ώστε να ικανοποιούνται οι ανάγκες ενός συστήματος. Εφαρμόζεται σε μια πληθώρα
|
||
πόρων όπως οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα δεδομένα. Η πιο
|
||
συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η οποία αποτελεί
|
||
και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να επιτευχθεί, απαιτείται η
|
||
χρήση ενός υπερ-επόπτη. Ένα λογισμικό υπεύθυνο για την κατάτμηση των φυσικών
|
||
πόρων ενός διακομιστή σε μια ή περισσότερες εικονικές αναπαραστάσεις ενός
|
||
συνόλου αυτών με σκοπό να χρησιμοποιηθούν ως ξεχωριστοί διακομιστές.
|
||
|
||
Για έναν υπερ-επόπτη υπάρχουν δύο κατηγορίες στις οποίες μπορεί να ανήκει. Είτε
|
||
πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης με το
|
||
υλικό, είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον
|
||
υποκείμενο διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη είναι άμεσα
|
||
εξαρτώμενη από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η ταχύτητα και η
|
||
απόδοση είναι υψίστης σημασίας, η άμεση πρόσβαση του υπερ-επόπτη τύπου 1 στο
|
||
υλικό συμβάλλει στην επίτευξη της διατήρησης των δύο αυτών προδιαγραφών σε
|
||
κατάλληλες τιμές. Από την άλλη, ένας υπερ-επόπτης τύπου 2 δεν έρχεται σε
|
||
αντιπαράθεση με το υποκείμενο ΛΣ και επιτρέπει την χρήση προγραμμάτων που το ΛΣ
|
||
πιθανόν να μην είναι σε θέση να εκτελέσει.
|
||
|
||
\clearpage
|
||
|
||
Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
|
||
επίτευξης της. Την πλήρη εικονικοποίηση και την παρα-εικονικοποίηση
|
||
\footfullcite{abacusFullParaOSVirtualization}. Στην πρώτη περίπτωση το
|
||
λειτουργικό σύστημα που εκτελείται στον εικονικό διακομιστή συμπεριφέρεται όπως
|
||
θα συμπεριφερόταν σε έναν φυσικό διακομιστή. Αυτό συμβαίνει διότι από μεριάς
|
||
του λειτουργικού συστήματος δεν υπάρχει επίγνωση της εικονικοποίησης που έχει
|
||
λάβει μέρος για να δημιουργηθούν οι εικονικοί πόροι στους οποίους στεγάζεται. Η
|
||
πλήρης εικονικοποίηση μπορεί να είναι δύο ειδών. Υποβοηθούμενη από το λογισμικό
|
||
ή από το υλικό. Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση ολόκληρου του
|
||
υλικού μέσω του υπερ-επόπτη που εκτελείται στο ΛΣ ενώ στο δεύτερο όπου δεν
|
||
υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του εικονικού διακομιστή να κάνει
|
||
χρήση της φυσικής κεντρικής μονάδας επεξεργασίας του διακομιστή φιλοξενίας εάν
|
||
αυτή το υποστηρίζει \footfullcite{geeksforgeeksHardwareAssistedVirtualization}.
|
||
Στην περίπτωση της παρα-εικονικοποίησης το λειτουργικό σύστημα αναγνωρίζει την
|
||
ύπαρξη του υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο ώστε να μπορούν
|
||
να επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό μειώνει την
|
||
συμβατότητα σε σχέση με την πλήρη εικονικοποίηση, η άμεση επικοινωνία του
|
||
λειτουργικού συστήματος με τον υπερ-επόπτη συμβάλλει στην αύξηση της
|
||
αποδοτικότητας.
|
||
|
||
\section{Εισαγωγή στα δοχεία και τον τρόπο λειτουργίας τους} \label{containerTechnologies}
|
||
|
||
Τα δοχεία αποτελούν και αυτά κομμάτι των τεχνολογιών εικονικοποίησης αλλά σε
|
||
επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
|
||
δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
|
||
(containerization). Σε αντίθεση με τις τεχνολογίες εικονικοποίησης που
|
||
αναφέρθηκαν στο \ref{virtualizationTechnologiesIntroduction}, για την
|
||
δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
|
||
παίρνει η μηχανή δοχείων. Επιπλέον, ενώ οι εικονικές μηχανές καταλήγουν να
|
||
περιέχουν εικονικό αντίγραφο του υλικού, δικό τους λειτουργικό σύστημα και
|
||
εγκατεστημένα πακέτα προς υποστήριξη ενός λογισμικού, τα δοχεία αποτελούνται
|
||
μονάχα από το λογισμικό προς εκτέλεση και τις εξαρτήσεις που χρειάζεται
|
||
προκειμένου να είναι λειτουργικό.
|
||
|
||
\clearpage
|
||
|
||
Τα απαραίτητα συστατικά για την επίτευξη της δοχειοποίησης είναι μια εικόνα
|
||
δοχείου και μια μηχανή δοχείων. Στην εικόνα δοχείου εμπεριέχονται τα συστατικά
|
||
μέρη ενός λογισμικού και οδηγίες συναρμολόγησής του προς ανάγνωση από την
|
||
μηχανή δοχείων. Από εκεί και πέρα, για την δημιουργία δοχείων υπάρχει μια
|
||
αλληλουχία βημάτων που πρέπει να έρθει εις πέρας. Αρχικά, η μηχανή δοχείων θα
|
||
προσπελάσει την εικόνα δοχείου προκειμένου να εξακριβώσει τις προδιαγραφές του.
|
||
Έπειτα, με την βοήθεια των μεθόδων απομόνωσης που έχει στην διάθεση της μέσω
|
||
των μηχανισμών εικονικοποίησης του πυρήνα του λειτουργικού συστήματος
|
||
φιλοξενίας, θα δημιουργήσει ένα εικονικό περιβάλλον απομονωμένο από το φυσικό
|
||
ήδη υπάρχον και τέλος, θα πραγματοποιήσει εκκίνηση του δοχείου ως διεργασία του
|
||
συστήματος.
|
||
|
||
Ορισμένα από αυτά τα βήματα περιλαμβάνουν και άλλες διαδικασίες για τις οποίες
|
||
είναι υπεύθυνα συγκεκριμένα προγράμματα με τα οποία συνεργάζεται η μηχανή
|
||
δοχείων. Υπάρχουν και μηχανές δοχείων χαμηλού επιπέδου έναντι των πιο γνωστών
|
||
υψηλού επιπέδου όπως το Docker, στις οποίες λείπουν λειτουργίες όπως η απόκτηση
|
||
εικόνων δοχείων από ένα κεντρικό αποθετήριο και ο έλεγχος εγκυρότητας των
|
||
ρυθμίσεων των εικόνων αυτών. Οι μηχανές δοχείων υψηλού επιπέδου είναι
|
||
ουσιαστικά μια συλλογή εργαλείων που διευκολύνουν την δοχειοποίηση
|
||
απαλλάσσοντας τον χρήστη από την ανάγκη της χειροκίνητης εκτέλεσης των βημάτων
|
||
της \footfullcite{sysdigContainerRuntime}.
|
||
|
||
Το τελικό επιθυμητό αποτέλεσμα είναι η δημιουργία ενός απομονωμένου
|
||
περιβάλλοντος στο οποίο πραγματοποιείται η εκτέλεση ενός λογισμικού με
|
||
βιβλιοθήκες και εξαρτήσεις διαφορετικών εκδόσεων συγκριτικά με αυτές που μπορεί
|
||
να προϋπάρχουν στο σύστημα. Το περιβάλλον αυτό είναι υποχρεωμένο να
|
||
χρησιμοποιήσει ένα υποσύνολο των πόρων του συστήματος που του απονεμήθηκε μέσω
|
||
της μηχανής δοχείων. Τα παραπάνω είναι εφικτά και με την χρήση εικονικών
|
||
μηχανών αλλά με κόστος την επιβάρυνση του συστήματος φιλοξενίας λόγω της
|
||
αδυναμίας διαμοιρασμού των πόρων με τον τρόπο που το επιτυγχάνουν τα δοχεία.
|
||
Κάθε δοχείο μοιράζεται τον πυρήνα του λειτουργικού συστήματος φιλοξενίας με τα
|
||
υπόλοιπα και κάθε στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα
|
||
στιγμιότυπο λογισμικού, δύναται να χρησιμοποιηθεί ταυτοχρόνως από περισσότερα
|
||
του ενός δοχεία προς αποφυγή διπλής αποθήκευσης
|
||
\footfullcite{codemotionContainerImages}. Επιπλέον, κάθε εικόνα δοχείου δύναται
|
||
να χρησιμοποιηθεί ως πρότυπο για την δημιουργία μιας καινούριας, καθιστώντας
|
||
έτσι ευκολότερη την επεκτασιμότητα ενός λογισμικού σε αντίθεση με τις εικονικές
|
||
μηχανές όπου κάθε νέο στιγμιότυπό τους απαιτεί την επαναληπτική εκτέλεση των
|
||
βημάτων δημιουργίας τους.
|
||
|
||
\subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}
|
||
|
||
Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux
|
||
διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
|
||
(λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
|
||
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών και
|
||
οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την δυνατότητα
|
||
περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα αρχείων. Με την
|
||
βοήθεια των εργαλείων που έχουν στην διάθεσή τους, δύναται να πραγματοποιηθεί
|
||
εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος εικονικοποίησης διακομιστών όπου ο
|
||
πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη πολλαπλών απομονωμένων περιβαλλόντων
|
||
\footfullcite{teimouriOsVirtualizationDefinition}, τα οποία συμπεριφέρονται ως
|
||
ξεχωριστοί διακομιστές \footfullcite{webopediaOsVirtualizationDefinition}.
|
||
|
||
Μια από τις υποχρεώσεις της μηχανής δοχείων είναι η επικοινωνία με τον πυρήνα
|
||
του λειτουργικού συστήματος φιλοξενίας για να επιτευχθεί αυτή η εικονικοποίηση.
|
||
Πρόκειται για μια διαδικασία κατά την οποία ένα λειτουργικό σύστημα επιτρέπει
|
||
την απομόνωση των διεργασιών που εκτελούνται σε χώρους ονομάτων και την ανάθεση
|
||
αποκλειστικών πόρων συστήματος σε αυτές. Με αυτό τον τρόπο, οι διεργασίες είναι
|
||
ανεξάρτητες μεταξύ τους και απομονωμένες ενώ διαμοιράζονται με ασφαλή τρόπο (σε
|
||
ένα βαθμό) τους πόρους του συστήματος. Ένα δοχείο μπορεί να θεωρηθεί πως
|
||
αντιστοιχεί σε μια τέτοια απομονωμένη διεργασία.
|
||
|
||
\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
|
||
|
||
Ενώ μια εικονική μηχανή είναι μια πλήρης αναπαράσταση ενός φυσικού διακομιστή,
|
||
ένα δοχείο εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Αυτό
|
||
σημαίνει πως εάν θεωρηθεί ως τελικός στόχος η εκτέλεση ενός λογισμικού
|
||
απομονωμένο από το υπόλοιπο σύστημα, αυτό επιτυγχάνεται με δύο διαφορετικούς
|
||
τρόπους αφού οι εικονικές μηχανές και τα δοχεία χρησιμοποιούν διαφορετικού
|
||
είδους εικονικοποίηση. Στην περίπτωση των δοχείων δεν έχουμε απομόνωση μηχανών
|
||
αλλά διεργασιών. Γεγονός που συμβάλλει στην αποφυγή της επιβάρυνσης του
|
||
συστήματος που θα επιβάλλονταν από τις διεργασίες του υπερ-επόπτη και της
|
||
καθυστέρησης που θα υπήρχε για την εκκίνηση ενός ολόκληρου λειτουργικού
|
||
συστήματος. Επιπλέον, η μη χρήση τεχνολογιών εικονικοποίησης σε επίπεδο υλικού
|
||
αυξάνει την μεταφερσιμότητα των δοχείων αφού σε μια εικόνα δοχείου μπορούν να
|
||
ορισθούν όλες οι απαραίτητες εξαρτήσεις ενός λογισμικού και να αναδημιουργηθούν
|
||
σε οποιοδήποτε περιβάλλον νέφους.
|
||
|
||
Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
|
||
αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
|
||
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
|
||
σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
|
||
εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
|
||
λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
|
||
εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
|
||
την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
|
||
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
|
||
βιβλιοθήκες και τις εξαρτήσεις της \footfullcite{ibmContainerVsVm}.
|
||
|
||
Το σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα στην
|
||
αρχιτεκτονική της εικονικοποίησης και των δοχείων:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||
\captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
|
||
\label{fig:containerVsVm}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\clearpage
|
||
|
||
Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
|
||
γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
|
||
σύμφωνα με τη Red Hat \footfullcite{redhatContainerVsVm}, το μέγεθος των
|
||
εικονικών μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της
|
||
τάξεως των megabyte. Πολλές φορές, όπως αναφέρεται και στο
|
||
\cite{ibmContainerVsVm} \footfullcite{ibmContainerVsVm}, τα δοχεία
|
||
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
|
||
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
|
||
της εφαρμογής που παίρνει την μορφή δοχείου. Με αυτόν τον τρόπο, είναι
|
||
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
|
||
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
|
||
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
|
||
περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
|
||
Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
|
||
πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
|
||
μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
|
||
αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
|
||
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
|
||
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
|
||
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
|
||
(δηλ. εικονικών ή φυσικών μηχανών) όπως είναι το Kubernetes ή το Docker Swarm.
|
||
|
||
Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
|
||
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
|
||
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
|
||
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
|
||
το ίδιο ισχύει και αντιστρόφως \footfullcite{containerOSlimitations}.
|
||
|
||
Εν γένει τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
|
||
μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
|
||
και η μεταφερσιμότητα τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
|
||
αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
|
||
σκοπό την στέγαση ενός ολόκληρου ξεχωριστού λειτουργικού συστήματος (όπως
|
||
γίνεται στις εικονικές μηχανές). Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε
|
||
οποιοδήποτε περιβάλλον είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως το
|
||
Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
|
||
σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
|
||
μη λειτουργικών απαιτήσεών τους.
|
||
|
||
\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}
|
||
|
||
Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει τους όρους Docker
|
||
και Container (δοχείο) αν και είναι διαφορετικοί. Παρόλα αυτά, η ιδέα της
|
||
δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
|
||
το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
|
||
είσοδο τους από το 1979, όταν εισήχθη το chroot \footfullcite{chrootCommand}
|
||
στην έβδομη έκδοση του Unix \footfullcite{containerHistory}. Πρόκειται για μια
|
||
εντολή που περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα
|
||
συγκεκριμένο φάκελο ο οποίος ορίζεται ως ο καινούριος διαχειριστικός (root). Ο
|
||
κύριος σκοπός του chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην
|
||
περίπτωση εκμετάλλευσης μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν
|
||
ανεπηρέαστα τα μέρη του συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση.
|
||
Εκείνη την εποχή αυτό ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό
|
||
αυξάνονταν και υπήρχε η ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από
|
||
κατασκευής του, το chroot δεν περιόριζε έναν χρήστη ή μια διεργασία με
|
||
διαχειριστικά δικαιώματα \footfullcite{chrootRestrictions}. Μερικά χρόνια
|
||
αργότερα, το 2004 δημιουργήθηκαν και ενσωματώθηκαν στον πυρήνα του Linux οι
|
||
ομάδες ελέγχου με την βοήθεια των οποίων ήταν πλέον δυνατή η απομόνωση πόρων
|
||
του συστήματος σε ένα υποσύνολο διεργασιών.
|
||
|
||
Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
|
||
2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
|
||
Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
|
||
εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
|
||
Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα επέτρεπε πλήρη
|
||
εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε αρκετές
|
||
λειτουργίες όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων. Παρόλα
|
||
αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
|
||
εφαρμογών \footfullcite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την
|
||
χρήση του όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||
|
||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων τα οποία χρησιμοποιούνται
|
||
ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
|
||
του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
|
||
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
|
||
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων
|
||
PaaS, παρέχοντας μια πλατφόρμα με μηχανισμούς για συναρμολόγηση, θέση σε
|
||
λειτουργία, εκτέλεση, ενημέρωση και διαχείριση προγραμμάτων σε μορφή δοχείων.
|
||
Σε αντίθεση με το LXC, αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο
|
||
στόχο την δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο
|
||
κώδικα, τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
|
||
(φιλοξενίας) παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων δοχείωv
|
||
όπως είναι το Docker Hub \footfullcite{dockerhub}, το επίσημο αποθετήριο του
|
||
Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή
|
||
οποιοδήποτε άλλο αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI
|
||
(Open Container Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι
|
||
χρήστες έχουν πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους
|
||
επιτρέπουν να ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής.
|
||
Επιπλέον, όντας μια μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα
|
||
απαιτούσαν εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν
|
||
συμπυκνωθεί σε απλές εντολές καθιστώντας έτσι εύκολη την χρήση του για
|
||
προγραμματιστές κάθε επιπέδου και απλοποιώντας κατά πολύ την διαδικασία
|
||
ανάπτυξης και παράδοσης κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς
|
||
τον χρήστη διεπαφή, έλεγχο εκδόσεων (version control) για δοχεία
|
||
\footfullcite{LXCvsDocker2} και ένα οικοσύστημα γύρω από όλα αυτά, είναι
|
||
εμφανής ο λόγος που κατάφερε να επισκιάσει το LXC.
|
||
|
||
\clearpage
|
||
|
||
\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
|
||
|
||
Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
|
||
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους όπως το μοντέλο καταρράκτη
|
||
(waterfall) \footfullcite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
|
||
αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
|
||
έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
|
||
αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
|
||
στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
|
||
\footfullcite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
|
||
πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
|
||
προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
|
||
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \footfullcite{devops}
|
||
όπου οι ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής
|
||
επικοινωνούν στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης
|
||
λογισμικού. Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD
|
||
(Continuous Integration/Continuous Delivery) \footfullcite{cicd}. Κατά το
|
||
μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες που εκτελούνται κατά
|
||
την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής προκειμένου να
|
||
πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να εντοπίζονται σφάλματα και
|
||
να παράγονται εκτελέσιμα πακέτα.
|
||
|
||
Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
|
||
και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
|
||
εφαρμογών και την εκτέλεσή τους σε οποιοδήποτε περιβάλλον. Λόγω των
|
||
χαρακτηριστικών τους, εξαλείφουν τυχόν προβλήματα ασυμβατότητας μεταξύ των
|
||
περιβαλλόντων εκτέλεσής τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων αφού
|
||
μπορεί κανείς να εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για
|
||
συγκεκριμένη ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
|
||
χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους. Γεγονός που
|
||
μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα.
|
||
Επιπλέον, λόγω της ταχείας διάθεσης και εκτέλεσής τους, συμβαδίζουν πλήρως με
|
||
τον ρυθμό ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
|
||
|
||
Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
|
||
προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
|
||
αρχιτεκτονική μικρο-υπηρεσιών. Σε αυτήν την περίπτωση, η εφαρμογή αποτελείται
|
||
από πολλά δοχεία όπου το κάθε ένα από αυτά είναι υπεύθυνο για μια συγκεκριμένη
|
||
λειτουργία της (μικρο-υπηρεσία). Τα δοχεία αυτά είναι ανεξάρτητα μεταξύ τους
|
||
και κατά την ανάγκη κλιμάκωσης μιας συγκεκριμένης λειτουργίας της εφαρμογής
|
||
αυτό μπορεί να επιτευχθεί δίχως την περιττή κλιμάκωση όλων των υπολοίπων.
|
||
Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ τους, καθιστά πιο σταθερή την
|
||
εφαρμογή αφού σε περίπτωση που κάποιο από αυτά αποτύχει, η υπόλοιπη εφαρμογή θα
|
||
συνεχίσει να λειτουργεί κανονικά και η ανακατασκευή του δοχείου που απέτυχε
|
||
μπορεί να επιτευχθεί εύκολα και γρήγορα με μια απλή τροποποίηση της εκάστοτε
|
||
εικόνας δοχείου.
|
||
|
||
\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
|
||
|
||
Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
|
||
τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
|
||
υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
|
||
συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
|
||
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι, η
|
||
εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
|
||
πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
|
||
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS (Container as a Service) όπως η
|
||
ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||
\footfullcite{caas} των υπηρεσιών IaaS (Infrastructure as a Service) όπου ένας
|
||
πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
|
||
σκοπού, παρέχει μια ευέλικτη υποδομή έτοιμη για την εκτέλεση δοχείων
|
||
\footfullcite{caasVsIaas}.
|
||
|
||
\clearpage
|
||
|
||
Από τις δύο αυτές επιλογές, η πιο δημοφιλής είναι η πρώτη καθώς προσφέρει μια
|
||
ευελιξία ως προς την διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι
|
||
χρήστες έχουν την δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές
|
||
ασφαλείας που μπορεί να έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν
|
||
επιπλέον λογισμικό παρακολούθησης και ελέγχου ποιότητας των δοχείων και να
|
||
προσαρμόσουν το περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η
|
||
ύπαρξη μιας επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου
|
||
συστήματος αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο
|
||
βρεθεί σε κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την
|
||
περιορισμένη έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη
|
||
την ανίχνευση και απομόνωση των προβλημάτων ασφαλείας όπως επίσης και την
|
||
αποκατάσταση τους.
|
||
|
||
Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
|
||
επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
|
||
διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
|
||
περιπτώσεις που οι χρήστες δεν έχουν την απαραίτητη εμπειρία σε αυτόν τον τομέα
|
||
ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
|
||
υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
|
||
υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
|
||
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων όπως η ταχεία διάθεση και
|
||
απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση. Συγκεκριμένα,
|
||
μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες ενορχήστρωσης δοχείων
|
||
\footfullcite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου στησίματος πλατφορμών
|
||
όπως το Kubernetes \footfullcite{kubernetes} και το Docker Swarm
|
||
\footfullcite{dockerSwarm}.
|
||
|
||
\clearpage
|
||
|
||
Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
|
||
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
|
||
επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
|
||
σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
|
||
διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
|
||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον ανάπτυξης
|
||
όπως μη συμβατές εκδόσεις προγραμμάτων και δυσκολία διαχείρισής τους
|
||
εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει έναν
|
||
συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
|
||
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
|
||
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
|
||
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
|
||
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
|
||
εφαρμογής \footfullcite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς
|
||
παρόχους με βάση τις ανάγκες τους.
|
||
|
||
\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
|
||
|
||
Μία από τις πιο σημαντικές προκλήσεις των επιχειρήσεων κατά την διάθεση
|
||
υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά κατά την
|
||
επιλογή χρήσης τεχνολογιών εικονικοποίησης, ανάμεσα στις επιλογές
|
||
εικονικοποίησης υλικού και εικονικοποίησης ΛΣ είθισται να προτιμάται η δεύτερη.
|
||
Μια λογική απόφαση εάν αναλογιστεί κανείς τα πλεονεκτήματα που προσφέρει τόσο
|
||
στην απόδοση πόρων του συστήματος όσο και στην αποδοτική αλλά και εύκολη
|
||
διαχείριση των υπηρεσιών όταν αυτές διατίθενται σε μορφή δοχείων. Παρ' όλα
|
||
αυτά, η επιλογή αυτή είναι και λιγότερο ασφαλής στην περίπτωση που αφεθεί στις
|
||
αρχικές ρυθμίσεις.
|
||
|
||
\clearpage
|
||
|
||
Για τον λόγο αυτό, εάν η μέγιστη δυνατή απόδοση δεν είναι μια από τις κύριες
|
||
προτεραιότητες της επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
|
||
συστήματος διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
|
||
μεταφερσιμότητα και την απαλλαγή από τις εξαρτήσεις του εκάστοτε προγράμματος
|
||
ακόμα και χωρίς την περαιτέρω διαμόρφωση των ρυθμίσεών του, η προτεινόμενη
|
||
χρήση είναι η εκτέλεσή του μέσω μιας εικονικής μηχανής. Η στρώση απομόνωσης
|
||
μέσω της εικονικοποίησης υλικού ανάμεσα στα προγράμματα και το μηχάνημα στο
|
||
οποίο εκτελούνται αποτελεί ένα παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας
|
||
επιτιθέμενος για να προκαλέσει ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα
|
||
να περάσει από τον εικονικό πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, ο
|
||
συνδυασμός με την αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο
|
||
απομόνωσης εφόσον στην προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα
|
||
του συστήματος αφορά το φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
|
||
|
||
Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
|
||
να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
|
||
τροποποίηση των ρυθμίσεων και του τρόπου λειτουργίας του Docker ώστε να
|
||
μπορέσει να επιτευχθεί μια ικανοποιητική ισορροπία μεταξύ της ασφάλειας και της
|
||
απόδοσης του συστήματος. Με βάση μια έρευνα που πραγματοποιήθηκε από την IBM
|
||
σχετικά με την ασφάλεια των δοχείων \footfullcite{containerSecurity}, βρέθηκε
|
||
πως ένα ορθώς ασφαλισμένο δοχείο μπορεί να παρέχει το ίδιο επίπεδο ασφάλειας με
|
||
μια εικονική μηχανή ή ακόμα και μεγαλύτερο. Συγκεκριμένα, στην έρευνα αυτή
|
||
αναφέρεται πως προκειμένου να ποσοτικοποιηθεί η ασφάλεια των δοχείων θα πρέπει
|
||
να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
|
||
χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
|
||
ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
|
||
αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
|
||
τότε είναι υπεύθυνος για περίπου το ίδιο ποσοστό υποδομών με τον πάροχο και
|
||
επωφελείται άμεσα από τις προσπάθειες ασφάλισης του παρόχου για το ποσοστό του.
|
||
Επομένως, συμπεραίνεται πως από την οπτική γωνία του τελικού χρήστη είναι πιο
|
||
ασφαλές να χρησιμοποιήσει τεχνολογίες εικονικοποίησης ΛΣ μέσω ενός παρόχου
|
||
νέφους για την παροχή των υπηρεσιών του
|
||
\footfullcite{containerSecurityExplained}.
|
||
|
||
\subsection{Πλεονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityAdvatnages}
|
||
|
||
Με τη χρήση της αρχιτεκτονικής δοχείων και ειδικότερα του Docker, έρχονται
|
||
αρκετά εγγενή οφέλη ασφαλείας \footfullcite{dockerInherentSecurity}. Ένα βασικό
|
||
όφελος αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν την
|
||
ακριβή κατανόηση του κώδικα που εκτελείται μέσα σε αυτά, σε αντίθεση με την
|
||
περίπτωση χρήσης αποκλειστικά εικονικών μηχανών. Επιπρόσθετα, κατά την εμφάνιση
|
||
προβλημάτων σε μία υπηρεσία με αρχιτεκτονική μικρο-υπηρεσιών που κάνει χρήση
|
||
δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.
|
||
|
||
Ένα εξίσου σημαντικό όφελος αποτελεί το επιπρόσθετο επίπεδο ασφάλειας που
|
||
παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρύνει το ΛΣ
|
||
φιλοξενίας (αν υπάρχει), ο υπερ-επόπτης, το φιλοξενούμενο ΛΣ και η εκτελούμενη
|
||
υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρύνει το ΛΣ που φιλοξενεί τη
|
||
μηχανή δοχείων, η μηχανή δοχείων και η υπηρεσία. Πράγμα που σημαίνει πως σε ένα
|
||
εικονικό περιβάλλον με την χρήση του Docker έχουμε επιπρόσθετα επίπεδα που
|
||
χρειάζονται σκλήρυνση. Συνεπώς, σε εικονικά περιβάλλοντα, η χρήση δοχείων
|
||
έρχεται με την σκλήρυνση ενός επιπλέον συστατικού, της μηχανής δοχείων, οπότε
|
||
προσφέρει καλύτερο επίπεδο ασφάλειας.
|
||
|
||
Δύο ακόμα σημαντικά πλεονεκτήματα είναι η ευκολία εφαρμογής ενημερώσεων
|
||
ασφαλείας στα δοχεία και η σταθερότητα του περιβάλλοντος που προσφέρεται μέσω
|
||
αυτών στις εφαρμογές. Ειδικότερα, η ενημέρωση ενός δοχείου είναι μια διαδικασία
|
||
δύο μόνο εντολών, ενώ το προσφερόμενο περιβάλλον είναι σταθερό με την λογική
|
||
πως η μηχανή δοχείου παρέχει ένα επίπεδο πάνω από το ΛΣ, κι επομένως το
|
||
περιβάλλον αυτό δεν είναι ξεχωριστά ευμετάβλητο από την εκάστοτε εφαρμογή που
|
||
εκτελείται μέσα σε αυτό. Άρα, δεν κινδυνεύει από νέα προβλήματα ασφαλείας που
|
||
θα μπορούσαν να επιφέρουν τυχόν ενημερώσεις των εξαρτήσεων της εφαρμογής χωρίς
|
||
την ταυτόχρονη ενημέρωση της εφαρμογής της ίδιας.
|
||
|
||
\clearpage
|
||
|
||
\subsection{Μειονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityDisadvantages}
|
||
|
||
Παρ' όλα τα προαναφερόμενα πλεονεκτήματα του Docker όπως η δυνατότητα απαλλαγής
|
||
από εξαρτήσεις του εκάστοτε συστήματος και η ευελιξία διαχείρισης των δοχείων
|
||
του, αυτό υπόκειται σε αρκετές ατασθαλίες σε σχέση με την ασφάλεια. Οι πιο
|
||
αξιοσημείωτες από αυτές είναι η ανάγκη εκτέλεσης του Docker με διαχειριστικά
|
||
δικαιώματα και η αρχικά ελαστικότερη απ' ό,τι χρειάζεται απομόνωσή του από τον
|
||
πυρήνα του συστήματος. Ο άμεσος αντίκτυπος των παραπάνω είναι πως τα δοχεία
|
||
είναι πιο ευάλωτα από άλλες τεχνολογίες σε επιθέσεις τύπου άρνησης υπηρεσιών
|
||
και σε επιθέσεις που εκμεταλλεύονται ευπάθειες του πυρήνα με σκοπό να ξεφύγουν
|
||
από το δοχείο και να αποκτήσουν πρόσβαση στο κύριο σύστημα (Container Escape
|
||
\footfullcite{containerEscapeTechniques}).
|
||
|
||
Το γεγονός που αυξάνει τον κίνδυνο κατά την διάρκεια μιας επίθεσης τύπου
|
||
άρνησης υπηρεσιών είναι πως σε αντίθεση με μια εικονική μηχανή όπου επιλέγεται
|
||
το εύρος πρόσβασης στους πόρους του συστήματος κατά τη δημιουργία της, η αρχική
|
||
ρύθμιση του Docker επιτρέπει στα δοχεία να χρησιμοποιήσουν το ίδιο ποσοστό
|
||
πόρων με το κύριο σύστημα, δηλαδή δεν υπάρχουν περιορισμοί. Επομένως, εάν ένα
|
||
δοχείο βρεθεί υπό τον έλεγχο ενός επιτιθέμενου, αυτό μπορεί δυνητικά να
|
||
εμποδίσει την εκτέλεση άλλων δοχείων ή ακόμα και την εκτέλεση άλλων εφαρμογών
|
||
που εκτελούνται στο σύστημα.
|
||
|
||
Σχετικά με τις επιθέσεις που αποσκοπούν στην απόκτηση πρόσβασης στο κύριο
|
||
σύστημα μέσω του δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
|
||
δοχείων σε συνδυασμό με τις αρχικές ρυθμίσεις ασφαλείας του Docker. Λόγω της
|
||
απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
|
||
ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
|
||
ένα δοχείο μπορεί να εκμεταλλευτεί μια ευπάθεια του πυρήνα προκειμένου να
|
||
αποκτήσει πρόσβαση στο κύριο σύστημα και εφόσον η εκτέλεση του Docker γίνεται
|
||
με διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape
|
||
θα έχει διαχειριστικά δικαιώματα και ο ίδιος
|
||
\footfullcite{containerEscapeRepercussions}.
|
||
|
||
\clearpage
|
||
|
||
\subsection{Ξεπερνώντας τα μειονεκτήματα ασφαλείας του Docker} \label{overcomingDockerDisadvantages}
|
||
|
||
Οι πιο συνήθεις τρόποι αντιμετώπισης της ανεπαρκούς προκαθορισμένης ασφάλειας
|
||
του Docker (δηλ. της ελαστικής απομόνωσης) είναι η ρύθμιση καλύτερων προφίλ
|
||
AppArmor ή κανόνων SELinux προκειμένου να απομονωθεί περισσότερο από το κύριο
|
||
σύστημα. Στην πραγματικότητα, αυτές οι πρακτικές λαμβάνουν υπόψιν τους κυρίως
|
||
τα δοχεία και όχι τη μηχανή δοχείων καθ' αυτού. Γι' αυτό τον λόγο, πολλές φορές
|
||
πρέπει να ακολουθούνται και καλύτερες πρακτικές κατά τη λειτουργία/χρήση του
|
||
Docker, όπως η αποφυγή χρήσης του διαχειριστικού λογαριασμού (σε διεργασίες)
|
||
όσον αφορά τα δοχεία και η αποφυγή λήψης δοχείων από μη έμπιστες πηγές. Υπάρχει
|
||
επομένως ανάγκη δημιουργίας ενός εργαλείου που αυτοματοποιημένα μπορεί να
|
||
δημιουργεί ασφαλή εικονικοποιημένα περιβάλλοντα, καθώς και να εγκαθιστά σε
|
||
αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας του Docker και των δοχείων
|
||
του, μια σκληρυμένη έκδοση του Docker.
|
||
|
||
Με τη χρήση του εργαλείου SecDep που θα περιγράψουμε παρακάτω στο κεφάλαιο
|
||
\ref{installationANDShowcase}, θα επιτευχθεί η ασφάλιση του Docker και του
|
||
συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές,
|
||
χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας
|
||
το Docker εξ ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο
|
||
αυτό επικοινωνεί με πολλούς παρόχους νέφους στέλνοντας τους παραμέτρους για τις
|
||
προδιαγραφές εικονικών μηχανών προκειμένου να μπορέσουν να δημιουργηθούν
|
||
αυτόματα, επιτρέποντας έτσι την δημιουργία πολλαπλών ασφαλών περιβαλλόντων ώστε
|
||
να μπορεί ένας χρήστης να εγκαθιστά εκεί τα δοχεία της εφαρμογής του. Η
|
||
σκλήρυνση του ΛΣ επιτυγχάνεται με την εκτέλεση πολλών βημάτων στα οποία μεταξύ
|
||
άλλων περιλαμβάνεται η σκλήρυνση του SSH, ο εντοπισμός, η εγκατάσταση, η
|
||
ρύθμιση και η ενεργοποίηση του κατάλληλου προγράμματος για ανάχωμα ασφαλείας
|
||
και για παροχή MAC (Mandatory Access Control) και η δημιουργία και ενεργοποίηση
|
||
περιοδικά εκτελέσιμων προγραμμάτων για την ενημέρωση του συστήματος και το
|
||
άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η απεξάρτηση από τον διαχειριστικό
|
||
λογαριασμό επιτυγχάνεται χάρη στη δουλειά του Akihiro Suda πάνω στο rootlesskit
|
||
\footfullcite{AkihiroSuda}, επιτρέποντας έτσι την χρήση ενός πλαστού
|
||
διαχειριστικού λογαριασμού προκειμένου να μπορέσει η μηχανή δοχείων να
|
||
εκτελεστεί υπό την κυριότητα οποιουδήποτε χρήστη του συστήματος. Τέλος, η
|
||
αντικατάσταση του αρχικού Container Runtime με το αντίστοιχο του gVisor
|
||
\footfullcite{gVisor}, εισάγει ένα πιο συμπαγές τείχος προστασίας απέναντι σε
|
||
συνηθισμένες επιθέσεις κατά των δοχείων, καθιστώντας το σύστημα μας πιο ασφαλές
|
||
συγκριτικά με τις αρχικές/προκαθορισμένες ρυθμίσεις.
|
||
|
||
\clearpage
|
||
|
||
\section{Δομή Εργασίας} \label{structure}
|
||
|
||
Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο κεφάλαιο \ref{background} θα
|
||
μελετήσουμε τον όρο νεφο-υπολογιστική, θα αναλύσουμε τις διάφορες τεχνολογίες
|
||
εικονικοποίησης και θα εμβαθύνουμε στην τεχνολογία των δοχείων με επίκεντρο την
|
||
ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το \ref{relevantWork}), θα
|
||
δούμε εργασίες σχετικές με την παρούσα και θα πραγματοποιηθεί ανάλυση και
|
||
σύγκριση αυτών με την προτεινόμενη εργασία της διπλωματικής. Αμέσως μετά, στο
|
||
κεφάλαιο \ref{projectDevelopment}, αναφερόμαστε στην ανάπτυξη του προτεινόμενου
|
||
εργαλείου και τα παράγωγά της (απαιτήσεις, σχεδιαστικά μοντέλα, κώδικα
|
||
υλοποίησης κα.). Προχωρώντας στο κεφάλαιο \ref{installationANDShowcase}, θα
|
||
αναφερθούμε στις οδηγίες εγκατάστασης και λειτουργίας του εργαλείου με βάση
|
||
στοχευμένα σενάρια χρήσης. Έπειτα, στο κεφάλαιο \ref{experimentationANDresults}
|
||
αποτιμάται η αποδοτικότητα του εργαλείου κατά την πραγματική χρήση του
|
||
προκειμένου να εξετασθεί με πρακτικό τρόπο η ικανότητα εξασφάλισης των στόχων
|
||
του. Τέλος, στο κεφάλαιο \ref{conclusions}, αναφέρονται δυνητικές επεκτάσεις
|
||
και βελτιώσεις του προτεινόμενου εργαλείου προκειμένου αυτό να μπορέσει να
|
||
πάρει μια θέση στην αγορά.
|