\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{cloudComputing}

Με τον όρο νεφο-υπολογιστική (Cloud Computing), αναφερόμαστε σε ένα μοντέλο
παράδοσης υπολογιστικών πόρων κατά παραγγελία από μια επιχείρηση προς τους
καταναλωτές της. Οι υπηρεσίες που προσφέρει χωρίζονται σε τρεις κατηγορίες. Η
πρώτη, SaaS (Software as a Service) αναφέρεται στην διάθεση λογισμικού του
οποίου οι λειτουργικές και μη λειτουργικές απαιτήσεις αποτελούν ευθύνη του
παρόχου. Η κατηγορία PaaS (Platform as a Service) ορίζεται ως η διάθεση
πλατφόρμας ανάπτυξης/εκτέλεσης λογισμικού όπου μονάχα οι μη λειτουργικές
απαιτήσεις του καλύπτονται από τον πάροχο. Τέλος, η κατηγορία IaaS
(Infrastructure as a Service) μεταφράζεται ως προσφορά απομακρυσμένων
διακομιστών τους οποίους μια επιχείρηση μπορεί να αξιοποιήσει αναλόγως τις
ανάγκες της ακολουθώντας φυσικά τους όρους και προϋποθέσεις του παρόχου. Τα
πλεονεκτήματα που παρέχει η νεφο-υπολογιστική σε σχέση με την παραδοσιακή
μέθοδο διάθεσης υπηρεσιών είναι αρκετά αλλά αυτά που ξεχωρίζουν από μεριάς των
πελατών είναι η απόλυτη απαλλαγή ευθύνης των υποδομών νέφους, η απαράμιλλη
ταχύτητα διάθεσης και κλιμάκωσης των υπηρεσιών και η εξάλειψη περιττού κόστους
λόγω του ευέλικτου μοντέλου χρέωσης όπου προσμετρώνται μόνο οι πόροι που
χρησιμοποιήθηκαν.

Σημαντικό ρόλο στην ευρεία αποδοχή των υπηρεσιών που προσφέρονται μέσω της
νεφο-υπολογιστικής είχε η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
μετέπειτα διαχείρισης τους. Σε κάθε περίπτωση γίνεται χρήση ενός API το οποίο
είναι προσπελάσιμο έμμεσα μέσω ενός γραφικού περιβάλλοντος (self-service
portal), εργαλείου γραμμής εντολών ή με προγραμματιστικό τρόπο (πχ. με τη χρήση
SDKs (Software Development Kits)).

\section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}

Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη της
εξαρτάται από 3 βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
νέφους και στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
που χρησιμοποιούνται όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους απομακρυσμένους
διακομιστές του και ο τελικός χρήστης εάν προβεί στην χρήση δοχείων. Ο τρίτος
και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες οφείλει να προβεί ο
χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την ασφάλεια σύμφωνα με τις
ανάγκες του.

Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
πλατφόρμες IaaS, προς διευκόλυνσή του η διαδικασία γίνεται και μέσω γραφικού
περιβάλλοντος της μορφής Point and Click. Στις εικονικές μηχανές που
προσφέρονται, τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τρόπο, η διαδικασία
δημιουργίας εικονικής μηχανής είναι αρκετά εύκολη για τον χρήστη, ο οποίος δεν
χρειάζεται να έχει ειδικές γνώσεις στο υλικό για να το πετύχει αυτό. Στην
προκειμένη περίπτωση, ενώ υπήρχε μηδενική δυσκολία για την απόκτηση εικονικής
μηχανής εξοπλισμένης με λειτουργικό σύστημα και πιθανότατα απαραίτητα για τον
χρήση προγράμματα, η ασφάλεια της δεν είναι πάντοτε εγγυημένη. Πολλά από τα
προγράμματα που θα χρησιμοποιήσει ο χρήστης δεν παρέχουν εξ αρχής
ενεργοποιημένες τις παραμέτρους ασφάλειας που μπορεί να υποστηρίζουν διότι δεν
δύναται να υπάρχει μια ασφαλής ρύθμιση που να καλύπτει όλα τα πιθανά σενάρια
χρήσης. Επιπλέον, η ρύθμιση των παραμέτρων ασφαλείας είναι μια διαδικασία που
απαιτεί εξειδικευμένες γνώσεις και είναι αρκετά εύκολο όχι μόνο να παραλειφθεί
αλλά και να γίνει λανθασμένα λόγω έλλειψης οικειότητας με τα εργαλεία που έχει
στην διάθεση του.

Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
ρυθμισμένα εκ τω προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
όπου υπάρχει τυφλή εμπιστοσύνη προς την ορθότητα των ρυθμίσεων αυτών σε
συνδυασμό με έλλειψη γνώσης των εργαλείων, ενδέχεται λόγω ανθρώπινου λάθους ή
στοχευμένα, να μένει ο τελικός χρήστης ευάλωτος σε ρίσκα ασφάλειας όπως μη
εξουσιοδοτημένη πρόσβαση, μόλυνση με κακόβουλο λογισμικό και υποκλοπές
ευαίσθητων προσωπικών δεδομένων. Στην περίπτωση που και ο πάροχος νέφους έχει
παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking
\footfullcite{Hyperjacking} και να αποκτήσει έλεγχο του υπερ-επόπτη με
αποτέλεσμα να είναι σε θέση να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές
μηχανές είτε στον διακομιστή στον οποίο εκτελείται.

\clearpage

\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 οι
ομάδες ελέγχου με την βοήθεια των οποίων ήταν πλέον δυνατή η απομόνωση πόρων
του συστήματος σε ένα υποσύνολο διεργασιών.

\clearpage

Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
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.

\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}, αναφέρονται δυνητικές επεκτάσεις
και βελτιώσεις του προτεινόμενου εργαλείου προκειμένου αυτό να μπορέσει να
πάρει μια θέση στην αγορά.
