Thesis/Chapters/1.Introduction.tex

\chapter{Εισαγωγή} \label{introduction}

\hyphenation{πολλαπλών}

\noindent Παραδοσιακά, όταν ένας χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας αποδοχής,
καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεων δεδομένων
(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα σημαντικό
κόστος.

Στις αρχές του 2000 ο τρόπος διεξαγωγής της παραπάνω διαδικασίας άλλαξε ριζικά
όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
τομέα του ηλεκτρονικού εμπορίου (e-commerce), δημιούργησε την θυγατρική της,
AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρεσίες
νεφο-υπολογιστικής (Cloud Computing Services) και συγκεκριμένα, την EC2
(Elastic Compute Cloud), μια υπηρεσία τύπου IaaS (Infrastructure as a Service)
(Υποδομή ως Υπηρεσία). Πρόκειται για την πρώτη υπηρεσία ενοικίασης
υπολογιστικών πόρων προς αξιοποίηση από οργανισμούς και επιχειρήσεις
προκειμένου να επιταχυνθεί η διαδικασία διάθεσης των δικών τους υπηρεσιών. Αυτό
το μοντέλο λειτουργίας παρέχει πολλά πλεονεκτήματα, όπως το μικρότερο κόστος
εκκίνησης διάθεσης υπηρεσιών, η διευκόλυνση κλιμάκωσής τους (είτε οριζόντιας
όπου μοιράζεται ο φόρτος εργασίας σε παραπάνω διακομιστές είτε κάθετης κατά την
οποία ένας διακομιστής αναβαθμίζεται με ισχυρότερες προδιαγραφές
\cite{cloudzeroScalability}) και η απαλλαγή ευθύνης σχετικά με την συνεχή
λειτουργία του εξοπλισμού στον οποίο στεγάζονται.

Λόγω της ευρείας αποδοχής των υπηρεσιών IaaS της AWS και των πολλών
πλεονεκτημάτων που αυτές παρέχουν, πολλές άλλες εταιρείες, όπως η Google, IBM
και Microsoft, άρχισαν να προσφέρουν και αυτές υπηρεσίες του ίδιου τύπου.
Σήμερα, ο μέσος καταναλωτής έχει στην διάθεσή του μια πληθώρα εταιρειών που
προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα μερικές από αυτές, όπως η
Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια υπηρεσία τους τη
δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με τη μορφή ενοικίασης
εικονικών μηχανών (Virtual Machines).

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

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

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

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

\section{Εικονικοποίηση και τεχνολογίες υλοποίησής της} \label{virtualizationTechnologiesIntroduction}

Η εικονικοποίηση αποτελεί μια τεχνολογία που επιτρέπει την διαμέριση πόρων ενός
φυσικού μηχανήματος σε πολλά μικρότερα υποσύνολα αυτών. Με αυτόν τον τρόπο,
καθίσταται ευκολότερη η διαχείρισή τους και αυξάνεται η απόδοση του υποκείμενου
υλικού, αφού μπορεί να χρησιμοποιείται στο έπακρον. Υπάρχουν πολλά είδη
εικονικοποίησης που αναλύονται πιο λεπτομερώς στο
\ref{virtualizationImplementations} αλλά οι δύο βασικότερες υλοποιήσεις της
είναι η εικονικοποίηση διακομιστών και λειτουργικών συστημάτων (δοχειοποίηση).

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

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

Τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το αποτέλεσμα της
εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την βοήθεια του
λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα οποία μπορούν
αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από το λειτουργικό
σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την εκτέλεση των
διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι βιβλιοθήκες
που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container image) την οποία
η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και με βάση αυτήν να
δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει.

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

\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}

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

Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
βιβλιοθήκες και τις εξαρτήσεις της \cite{ibmContainerVsVm}.

\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
στην αρχιτεκτονική της εικονικοποίησης και των δοχείων.

\begin{center}
\begin{figure}[!ht]
\centering
    \includegraphics[width = \textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
    \captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
    \label{fig:containerVsVm}
\end{figure}
\vspace*{-30pt}
\end{center}

Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
όπως το Docker Compose.

Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.

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

\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}

Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει τους όρους Docker
και Container (δοχείο) αν και είναι διαφορετικοί. Παρ' όλα αυτά, η ιδέα της
δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
είσοδό τους από το 1979, όταν εισήχθη το chroot \cite{chrootCommand} στην
έβδομη έκδοση του Unix \cite{containerHistory}. Πρόκειται για μια εντολή που
περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα συγκεκριμένο
φάκελο, ο οποίος ορίζεται ως ο καινούριος αρχικός (root). Ο κύριος σκοπός του
chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην περίπτωση εκμετάλλευσης
μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν ανεπηρέαστα τα μέρη του
συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση. Εκείνη την εποχή αυτό
ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό αυξάνονταν και υπήρχε η
ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από κατασκευής του, το chroot
δεν περιόριζε έναν χρήστη ή μια διεργασία με διαχειριστικά δικαιώματα
\cite{chrootRestrictions}. Μερικά χρόνια αργότερα, το 2004 δημιουργήθηκαν και
ενσωματώθηκαν στον πυρήνα του Linux οι ομάδες ελέγχου, με την βοήθεια των
οποίων ήταν πλέον δυνατή η απομόνωση πόρων του συστήματος σε ένα υποσύνολο
διεργασιών.

Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα, επέτρεπε
πλήρη εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε
αρκετές λειτουργίες όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων.
Παρ' όλα αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.

Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
(Platform-as-a-Service) (Πλατφόρμα ως Υπηρεσία) και παρέχει μια πλατφόρμα με
μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση, ενημέρωση και
διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC, αποτελεί μια
μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την δοχειοποίηση εφαρμογών. Εκτός
από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα, τις βιβλιοθήκες και εξαρτήσεις
ενός λογισμικού από το κύριο σύστημα (φιλοξενίας), παρέχει και δυνατότητες
επικοινωνίας με αποθετήρια εικόνων δοχείωv, όπως είναι το Docker Hub
\footfullcite{dockerhub}, το επίσημο αποθετήριο του Docker, το Quay
\footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή οποιοδήποτε άλλο
αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI (Open Container
Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι χρήστες έχουν
πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να
ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια
μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα απαιτούσαν
εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε
απλές εντολές, καθιστώντας έτσι εύκολη την χρήση του για προγραμματιστές κάθε
επιπέδου και απλοποιώντας κατά πολύ την διαδικασία ανάπτυξης και παράδοσης
κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή,
έλεγχο εκδόσεων (version control) για δοχεία \cite{LXCvsDocker2} και ένα
οικοσύστημα γύρω από όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει
το LXC.

\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}

Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο καταρράκτη
(waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
\cite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \cite{devops} όπου οι
ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής επικοινωνούν
στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης λογισμικού.
Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD (Continuous
Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής Παράδοση)
\cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες
που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής
προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα τα οποία μετά μπορούν
απευθείας να διατίθενται στο κοινό (continuous deployment).

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

\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}

Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι: η
εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS \cite{caas} (Container as a
Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπηρεσία όπου
ένας πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
σκοπού, παρέχει μια ευέλικτη υποδομή, έτοιμη για την εκτέλεση δοχείων
\cite{caasVsIaas}.

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

Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
περιπτώσεις που οι χρήστες δεν έχουν την απαραίτητη εμπειρία σε αυτόν τον τομέα
ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων, όπως η ταχεία διάθεση
και απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση.
Συγκεκριμένα, μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες
ενορχήστρωσης δοχείων χωρίς την ανάγκη χειροκίνητου στησίματος πλατφορμών όπως
το Kubernetes \cite{kubernetes} και το Docker Swarm \cite{dockerSwarm}, που
παρέχουν αυτή την δυνατότητα.

Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και η δυσκολία διαχείρισής
τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς παρόχους
με βάση τις ανάγκες τους.

\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}

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

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

Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
τροποποίηση των ρυθμίσεων και του τρόπου λειτουργίας του Docker ώστε να
μπορέσει να επιτευχθεί μια ικανοποιητική ισορροπία μεταξύ της ασφάλειας και της
απόδοσης του συστήματος. Με βάση μια έρευνα που πραγματοποιήθηκε από την IBM
σχετικά με την ασφάλεια των δοχείων \cite{containerSecurity}, βρέθηκε πως ένα
ορθώς ασφαλισμένο δοχείο μπορεί να παρέχει το ίδιο επίπεδο ασφάλειας με μια
εικονική μηχανή ή ακόμα και μεγαλύτερο. Συγκεκριμένα, στην έρευνα αυτή
αναφέρεται πως προκειμένου να ποσοτικοποιηθεί η ασφάλεια των δοχείων θα πρέπει
να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
τότε είναι υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας
επίθεσης συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες
ασφάλισης του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την
οπτική γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
εικονικοποίησης ΛΣ μέσω ενός παρόχου νέφους για την παροχή των υπηρεσιών του
\cite{containerSecurityExplained}.

\subsection{Πλεονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityAdvatnages}

Με τη χρήση της αρχιτεκτονικής δοχείων και ειδικότερα του Docker, έρχονται
αρκετά εγγενή οφέλη ασφαλείας \cite{dockerInherentSecurity}. Ένα βασικό όφελος
αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν την ακριβή
κατανόηση του κώδικα που εκτελείται μέσα σε αυτά, σε αντίθεση με την περίπτωση
χρήσης αποκλειστικά εικονικών μηχανών. Επιπρόσθετα, κατά την εμφάνιση
προβλημάτων σε μία υπηρεσία με αρχιτεκτονική μικρο-υπηρεσιών που κάνει χρήση
δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.

Ένα εξίσου σημαντικό όφελος αποτελεί το επιπρόσθετο επίπεδο ασφάλειας που
παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρύνει το ΛΣ
φιλοξενίας (αν υπάρχει), ο υπερ-επόπτης, το φιλοξενούμενο ΛΣ και η εκτελούμενη
υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρύνει το ΛΣ που φιλοξενεί τη
μηχανή δοχείων, η μηχανή δοχείων και η υπηρεσία. Πράγμα που σημαίνει πως σε ένα
εικονικό περιβάλλον, με την χρήση του Docker έχουμε επιπρόσθετα επίπεδα που
χρειάζονται σκλήρυνση. Συνεπώς, σε εικονικά περιβάλλοντα, η χρήση δοχείων
έρχεται με την σκλήρυνση ενός επιπλέον συστατικού, της μηχανής δοχείων, οπότε
προσφέρει καλύτερο επίπεδο ασφάλειας.

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

\subsection{Μειονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityDisadvantages}

Παρ' όλα τα προαναφερόμενα πλεονεκτήματα του Docker, όπως η δυνατότητα
απαλλαγής από εξαρτήσεις του εκάστοτε συστήματος και η ευελιξία διαχείρισης των
δοχείων του, αυτό εμφανίζει αρκετές τρωτότητες σε σχέση με την ασφάλεια. Οι πιο
αξιοσημείωτες από αυτές είναι η ανάγκη εκτέλεσης του Docker με διαχειριστικά
δικαιώματα και η αρχικά ελαστικότερη απ' ό,τι χρειάζεται απομόνωσή του από τον
πυρήνα του συστήματος. Ο άμεσος αντίκτυπος των παραπάνω είναι πως τα δοχεία
είναι πιο ευάλωτα από άλλες τεχνολογίες σε επιθέσεις τύπου άρνησης υπηρεσιών
και σε επιθέσεις που εκμεταλλεύονται ευπάθειες του πυρήνα με σκοπό να ξεφύγουν
από το δοχείο και να αποκτήσουν πρόσβαση στο κύριο σύστημα μέσω αυτού
(Container Escape \cite{containerEscapeTechniques}).

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

Σχετικά με τις επιθέσεις που αποσκοπούν στην απόκτηση πρόσβασης στο κύριο
σύστημα μέσω του δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
δοχείων σε συνδυασμό με τις αρχικές ρυθμίσεις ασφαλείας του Docker. Λόγω της
απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
ένα δοχείο μπορεί να εκμεταλλευτεί μια ευπάθεια του πυρήνα προκειμένου να
αποκτήσει πρόσβαση στο κύριο σύστημα - εφόσον η εκτέλεση του Docker γίνεται με
διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape θα
έχει διαχειριστικά δικαιώματα και ο ίδιος \cite{containerEscapeRepercussions}.

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