\chapter{Υπόβαθρο} \label{background}

\hyphenation{πολλές μελών/οργανισμών ανάπτυξης}

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

\section{Νεφο-υπολογιστική} \label{cloudComputing}

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

Σημαντικό ρόλο στην ευρεία αποδοχή των υπηρεσιών που προσφέρονται μέσω της
νεφο-υπολογιστικής έχει η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
μετέπειτα διαχείρισής τους. Σε κάθε περίπτωση γίνεται χρήση ενός API
(Application Programming Interface) (Προγραμματιστική Διεπαφή Εφαρμογής), το
οποίο είναι προσπελάσιμο έμμεσα μέσω ενός γραφικού περιβάλλοντος (self-service
portal) ή ενός εργαλείου γραμμής εντολών (command line tool) ή άμεσα με
προγραμματιστικό τρόπο (πχ. με τη χρήση SDKs (Software Development Kits) (Κιτ
Ανάπτυξης Λογισμικού)).

\subsection{Ορισμός Νεφο-Υπολογιστικής} \label{cloudComputingDefinition}

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

\subsection{Χαρακτηριστικά} \label{cloucComputingCharacteristics}

Τα πέντε βασικά χαρακτηριστικά της νεφο-υπολογιστικής με βάση τους
\textcite{mell2011nist} είναι τα εξής:

\begin{itemize}

    \item \textbf{Αυτοεξυπηρέτηση κατά παραγγελία (On-demand Self-service)}:

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

    \item \textbf{Πανταχού παρούσα πρόσβαση (Ubiquitous Access)}:

        Οι υπηρεσίες που παρέχονται είναι διαθέσιμες μέσω του διαδικτύου και
        είναι προσβάσιμες μέσω πρότυπων μηχανισμών από ετερογενείς πλατφόρμες
        λεπτών και πυκνών πελατών (thin \& thick clients).

\clearpage

    \item \textbf{Πολλαπλή Μίσθωση (Multi-Tenancy)}:

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

    \item \textbf{Ελαστικότητα (Elasticity)}:

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

    \item \textbf{Μετρούμενη υπηρεσία (Measured Service)}:

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

\end{itemize}

\clearpage

\subsection{Μοντέλα Υπηρεσιών/Παράδοσης} \label{cloudComputingServiceModels}

Τα τρία μοντέλα υπηρεσιών ή παράδοσης της νεφο-υπολογιστικής, όπως αυτά
αναγράφονται στο \cite{mell2011nist}, είναι τα παρακάτω:

\begin{itemize}

    \item \textbf{Software as a Service (SaaS) (Λογισμικό ως Υπηρεσία)}:

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

    \item \textbf{Platform as a Service (PaaS) (Πλατφόρμα ως Υπηρεσία)}:

        Παρέχεται η δυνατότητα ανάπτυξης και εκτέλεσης εφαρμογών σε ένα
        κατάλληλο περιβάλλον παρεχόμενο από μια πλατφόρμα που υποστηρίζεται από
        πόρους του υπολογιστικού νέφους. Οι εφαρμογές αυτές αναπτύσσονται από
        τον καταναλωτή μέσω της πλατφόρμας χρησιμοποιώντας ένα ολοκληρωμένο
        περιβάλλον ανάπτυξης και εκτέλεσης αποτελούμενο από runtimes γλωσσών
        προγραμματισμού, βιβλιοθήκες, υπηρεσίες και εργαλεία ανάπτυξης. Ο
        καταναλωτής δεν έχει τον έλεγχο της υποκείμενης υποδομής νέφους, αλλά
        έχει τον έλεγχο των εφαρμογών που εκτελούνται σε αυτήν, των δεδομένων
        τους, καθώς και των ρυθμίσεων διαμόρφωσής τους και του περιβάλλοντος
        ανάπτυξης/εκτέλεσής τους. Συνήθως, τα περιβάλλοντα είναι προκαθορισμένα
        ως προς το περιεχόμενο τους. Όμως, γίνεται προσπάθεια από τους παρόχους
        των υπηρεσιών PaaS να καλύψουν τις ανάγκες όλων των πιθανών ομάδων
        έργων λογισμικού παρέχοντας μια μεγάλη ποικιλία από διαφορετικά
        περιβάλλοντα. Το μοντέλο χρέωσης υπηρεσιών PaaS συνήθως περιλαμβάνει
        μια σταθερή χρέωση ανά χρονική περίοδο για κάθε είδος πόρου που
        χρειάστηκε να χρησιμοποιηθεί από τον πάροχο για την επίτευξη των
        απαιτήσεων της εφαρμογής του καταναλωτή μέσω της παρεχόμενης πλατφόρμας
        \cite{paasPricingModel}. Ουσιαστικά, ο καταναλωτής χρεώνεται με βάση
        την χρήση των πόρων του παρόχου.

\clearpage

    \item \textbf{Infrastructure as a Service (IaaS) (Υποδομή ως Υπηρεσία)}:

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

\end{itemize}

\subsection{Μοντέλα Ανάπτυξης} \label{cloudComputingDeploymentModels}

Τα τέσσερα μοντέλα ανάπτυξης του υπολογιστικού νέφους σύμφωνα με το
\cite{mell2011nist} και την \citeauthor{cloudDeploymentModels}
\cite{cloudDeploymentModels} είναι τα εξής:

\begin{itemize}

    \item \textbf{Ιδιωτικό νέφος (Private Cloud)}:

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

\clearpage

    \item \textbf{Κοινοτικό νέφος (Community Cloud)}:

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

    \item \textbf{Δημόσιο νέφος (Public Cloud)}:

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

    \item \textbf{Υβριδικό νέφος (Hybrid Cloud)}:

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

\end{itemize}

\section{Εικονικοποίηση} \label{virtualization}

Η εικονικοποίηση (virtualization) είναι ένας όρος που χρησιμοποιούμε όταν
θέλουμε να αναφερθούμε στην αναπαράσταση πόρων σε εικονική μορφή με σκοπό την
αναδιαμόρφωσή τους ούτως ώστε να ικανοποιούνται οι ανάγκες ενός συστήματος
(όπως η αύξηση της χρήσης των φυσικών του πόρων). Εφαρμόζεται σε μια πληθώρα
πόρων, όπως είναι οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα
δεδομένα. Η πιο συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η
οποία αποτελεί και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να
επιτευχθεί, απαιτείται η χρήση ενός υπερ-επόπτη. Δηλαδή, ενός λογισμικού
υπεύθυνου για την κατάτμηση των φυσικών πόρων ενός διακομιστή σε μια ή
περισσότερες εικονικές αναπαραστάσεις ενός συνόλου αυτών με σκοπό να
χρησιμοποιηθούν ως ξεχωριστοί εικονικοί διακομιστές (virtual hosts/servers) (οι
κοινώς λεγόμενες εικονικές μηχανές).

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

Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
επίτευξης της: την πλήρη εικονικοποίηση (full virtualization) και την
παρα-εικονικοποίηση \cite{abacusFullParaOSVirtualization} (paravirtualization).
Στην πρώτη περίπτωση το λειτουργικό σύστημα που εκτελείται στον εικονικό
διακομιστή συμπεριφέρεται όπως θα συμπεριφερόταν σε έναν φυσικό διακομιστή.
Αυτό συμβαίνει διότι από μεριάς του λειτουργικού συστήματος δεν υπάρχει
επίγνωση της εικονικοποίησης που έχει λάβει μέρος για να δημιουργηθούν οι
εικονικοί πόροι στους οποίους στεγάζεται. Η πλήρης εικονικοποίηση μπορεί να
είναι δύο ειδών: υποβοηθούμενη από το λογισμικό (software-assisted) ή από το
υλικό (hardware assisted). Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση
ολόκληρου του υλικού μέσω του υπερ-επόπτη (τύπου 2) που εκτελείται στο ΛΣ. Στο
δεύτερο είδος, όπου δεν υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του
εικονικού διακομιστή να κάνει χρήση της φυσικής κεντρικής μονάδας επεξεργασίας
του διακομιστή φιλοξενίας εάν αυτή το υποστηρίζει
\cite{geeksforgeeksHardwareAssistedVirtualization}.

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

\subsection{Ορισμός Εικονικοποίησης} \label{virtualizationDefinition}

Σύμφωνα με τον ορισμό της Red Hat \cite{redhatVirtualizationDefinition}, η
εικονικοποίηση είναι μια τεχνολογία που μας επιτρέπει να δημιουργήσουμε
πολλαπλά εικονικά περιβάλλοντα ή αποκλειστικούς πόρους από ένα μόνο, φυσικό
σύστημα υλικού. Ένα λογισμικό ονόματι υπερ-επόπτης (hypervisor) συνδέεται στο
υλικό αυτό\footnote{\textgreek{Απευθείας στην εικονικοποίηση υποβοηθούμενη από
το υλικό και έμμεσα στην εικονικοποίηση υποβοηθούμενη από το λογισμικό.}} και
δίνει τη δυνατότητα διαμερισμού ενός συστήματος σε ξεχωριστά, διακριτά και
ασφαλή περιβάλλοντα, γνωστά και ως εικονικές μηχανές (Virtual Machines - VMs).
Επομένως, αυτές οι εικονικές μηχανές βασίζονται στην ικανότητα του υπερ-επόπτη
να διαχωρίζει τους πόρους της μηχανής και να τους κατανέμει κατάλληλα.

Το φυσικό υλικό, εξοπλισμένο με έναν υπερ-επόπτη, ονομάζεται ξενιστής (host) ή
μηχάνημα φιλοξενίας (hosting machine), ενώ οι πολλές εικονικές μηχανές που
χρησιμοποιούν τους πόρους του είναι οι επισκέπτες (guests) ή αλλιώς τα
φιλοξενούμενα μηχανήματα (hosted machines). Οι επισκέπτες, αντιμετωπίζουν τους
υπολογιστικούς πόρους, όπως είναι η κεντρική μονάδα επεξεργασίας, η μνήμη και ο
αποθηκευτικός χώρος, ως μια δεξαμενή πόρων που μπορεί εύκολα να ανακατανεμηθεί.
Οι χειριστές (operators) μπορούν να ελέγχουν εικονικά στιγμιότυπα αυτών των
πόρων, ούτως ώστε να πραγματοποιούν οριζόντια ή κάθετη κλιμάκωση. Δηλαδή είτε
να δημιουργούν περισσότερες εικονικές μηχανές, είτε να αναδημιουργούν την ίδια
με επιπλέον πόρους (εφόσον αυτοί δεν έχουν δεσμευτεί από άλλες εικονικές
μηχανές του ίδιου φυσικού μηχανήματος) όταν αυτό είναι απαραίτητο.

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

Με βάση ένα παράδειγμα της Red Hat \cite{redhatVirtualization}, ας φανταστούμε
πως έχουμε τρεις φυσικούς διακομιστές (servers) (δηλ. φυσικά μηχανήματα), στον
καθένα από τους οποίους φιλοξενείται ένα συγκεκριμένο συστατικό (component)
(λογισμικού): ένας διακομιστής ηλεκτρονικού ταχυδρομείου (email server), ένας
διακομιστής ιστού (web server) και ένας διακομιστής που εκτελεί εσωτερικές
εταιρικές εφαρμογές κληρονομιάς (οι οποίες σταμάτησαν να διατηρούνται αλλά
είναι ακόμα λειτουργικές), αντίστοιχα. Στο συγκεκριμένο παράδειγμα κάθε ένας
από τους (φυσικούς) διακομιστές χρησιμοποιεί μονάχα το 30\% των δυνατοτήτων του
(ως προς τους πόρους που μπορεί να διαθέσει).

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

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

\begin{center}
\begin{figure}[!ht]
\centering
    \includegraphics[width = .9\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage2.png}
    \captionof{figure}{Χρήση διακομιστών με εικονικοποίηση \cite{redhatVirtualization}}
    \label{fig:virtualizationServerUsage2}
\end{figure}
\vspace*{-30pt}
\end{center}

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

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

\subsection{Ιστορική αναδρομή της εικονικοποίησης} \label{virtualizationHistory}

Όπως αναφέρει μια θυγατρική της IBM \cite{redhatVirtualization}, ενώ η
τεχνολογία εικονικοποίησης χρονολογείται από τη δεκαετία του 1960, δεν
υιοθετήθηκε ευρέως μέχρι τις αρχές της δεκαετίας του 2000. Οι τεχνολογίες που
την έκαναν πραγματικότητα, όπως οι υπερ-επόπτες, αναπτύχθηκαν πριν από
δεκαετίες για να δώσουν σε πολλούς χρήστες ταυτόχρονη πρόσβαση σε υπολογιστές
που επεξεργαζόντουσαν πολλά δεδομένα ταυτόχρονα. Κάτι ιδιαίτερα δημοφιλές στον
τομέα των επιχειρήσεων για καθήκοντα ρουτίνας (routine tasks) που έπρεπε να
εκτελεστούν χιλιάδες φορές και πολύ γρήγορα όπως η μισθοδοσία υπαλλήλων.

Ωστόσο, μέσα στις επόμενες δεκαετίες, ήρθαν στο προσκήνιο άλλες λύσεις στο
πρόβλημα διαμοιρασμού ενός μηχανήματος σε πολλούς χρήστες, μειώνοντας έτσι το
ενδιαφέρον για την τεχνολογία εικονικοποίησης. Μία από αυτές ήταν ο
διαμοιρασμός χρόνου (time-sharing), όπου ένας χρήστης μπορούσε να χρησιμοποιεί
το λειτουργικό σύστημα απομονωμένα από τους υπόλοιπους. Κάτι που οδήγησε στη
δημιουργία λειτουργικών συστημάτων όπως το UNIX, το οποίο με τη σειρά του
άνοιξε το δρόμο για την άφιξη του Linux. Καθ' όλη τη διάρκεια αυτή, η
εικονικοποίηση παρέμεινε σε μεγάλο βαθμό μη διαδεδομένη.

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

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

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

\section{Τι είναι ένας υπερ-επόπτης} \label{hypervisors}

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

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

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

\subsection{Είδη υπερ-εποπτών} \label{hypervisorTypes}

Οι υπερ-επόπτες χωρίζονται σε δύο κατηγορίες ανάλογα με το περιβάλλον στο οποίο
εκτελούνται. Με βάση την \citeauthor{ibmHypervisorDefinition}
\cite{ibmHypervisorDefinition}, αυτές είναι:

\begin{itemize}

    \item \textbf{Τύπου 1 (Bare Metal)}:

        Ένας υπερ-επόπτης τύπου 1 εκτελείται απευθείας στο φυσικό υλικό του
        υποκείμενου υπολογιστή, αλληλεπιδρώντας άμεσα με την κεντρική μονάδα
        επεξεργασίας, τη μνήμη και το φυσικό αποθηκευτικό χώρο. Για το λόγο
        αυτό, οι υπερ-επόπτες τύπου 1 αναφέρονται επίσης ως bare-metal
        υπερ-επόπτες και αντικαθιστούν το λειτουργικό σύστημα του κεντρικού
        υπολογιστή. Η άμεση πρόσβαση στο φυσικό υλικό, τους καθιστά ιδιαίτερα
        αποδοτικούς. Παρ' όλα αυτά, επειδή αντικαθιστούν το ΛΣ, προκειμένου να
        μπορούν να αξιοποιηθούν απομακρυσμένα, συχνά απαιτείται μια ξεχωριστή
        μηχανή στην οποία θα εκτελείται λογισμικό διαχείρισης εικονικών πόρων
        \cite{phoenixnapHypervisors}, μέσω του οποίου προσφέρεται μια διεπαφή
        για τον έλεγχο των εικονικών μηχανών και του υλικού του κεντρικού
        υπολογιστή.

    \item \textbf{Τύπου 2 (Hosted)}:

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

\end{itemize}

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

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

\subsection{Χαρακτηριστικά ενός υπερ-επόπτη}  \label{hypervisorCharacteristics}

Αν και υπάρχουν διαφορετικά είδη υπερ-εποπτών, όλοι έχουν κάποια χαρακτηριστικά
που πρέπει να λάβει κανείς υπόψιν όταν επιλέγει ποιον θα χρησιμοποιήσει. Μερικά
σημαντικά αυτών, όπως αναφέρονται από την \citeauthor{ibmHypervisorDefinition}
\cite{ibmHypervisorDefinition}, είναι:

\begin{itemize}

    \item \textbf{Απόδοση}:

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

    \item \textbf{Οικοσύστημα}:

        Για τη διαχείριση ενός υπερ-επόπτη σε διάφορες κλίμακες πρέπει να
        υπάρχει καλή τεκμηρίωση και διάφορα εργαλεία είτε επίσημα είτε από την
        κοινότητα που να επιτρέπουν δυνατότητες, όπως δημιουργία αντιγράφων
        ασφαλείας, ανάλυση χωρητικότητας και διαχείριση εναλλαγής εικονικών
        μηχανών \cite{vmfailover} με αντίγραφα τους σε περιπτώσεις σφάλματος
        του λειτουργικού συστήματος της εκτελούμενης (εικονικής μηχανής).

    \item \textbf{Εργαλεία διαχείρισης}:

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

    \item \textbf{Μεταφορά κατά τη λειτουργία}:

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

    \item \textbf{Κόστος}:

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

\end{itemize}

\subsection{Επιλογή υπερ-επόπτη} \label{hypervisorSelection}

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

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

\section {Τρόπος λειτουργίας της εικονικοποίησης} \label{virtualizationOperation}

Για να πραγματοποιηθεί η εικονικοποίηση, χρειαζόμαστε έναν υπερ-επόπτη. Δηλαδή
ενός λογισμικού που διαχωρίζει τους φυσικούς πόρους από τα εικονικά
περιβάλλοντα, τα οποία τους χρειάζονται. Ένας υπερ-επόπτης μπορεί να
τοποθετηθεί πάνω σε ένα λειτουργικό σύστημα ή να εγκατασταθεί απευθείας στο
υλικό. Η τελευταία εναλλακτική είναι αυτή που επιλέγουν οι περισσότερες
επιχειρήσεις για λόγους αποδοτικότητας αφού θα βρίσκεται μια στρώση πιο κοντά
στο υλικό το οποίο θα διαχειρίζεται. Η δουλειά ενός υπερ-επόπτη είναι
ουσιαστικά να λάβει τους φυσικούς πόρους ενός (φυσικού) μηχανήματος και να τους
χωρίσει με τέτοιο τρόπο ώστε να μπορούν να χρησιμοποιηθούν από τα εικονικά μας
περιβάλλοντα \cite{redhatVirtualization}.

\begin{center}
\begin{figure}[!ht]
\centering
    \includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_architecture.png}
    \captionof{figure}{Υπερ-επόπτης πάνω σε διακομιστές \cite{redhatVirtualization}}
    \label{fig:hypervisorOnServers}
\end{figure}
\vspace*{-30pt}
\end{center}

Μετά τη δημιουργία μιας εικονικής μηχανής, οι χρήστες αλληλεπιδρούν με αυτή
όπως θα αλληλεπιδρούσαν με μια φυσική. Οι εικονικές μηχανές έχουν τη μορφή ενός
ενιαίου αρχείου, πράγμα που καθιστά εύκολη τη μεταφορά και ανάγνωσή τους από
οποιονδήποτε υπολογιστή αναμένοντας τον ίδιο τρόπο λειτουργίας. Κατά την
εκτέλεση του εικονικού περιβάλλοντος, όταν ένας χρήστης ή ένα πρόγραμμα εκδώσει
μία εντολή που απαιτεί περισσότερους πόρους από τους διαθέσιμούς του, ο
υπερ-επόπτης είτε αναμεταδίδει το αίτημα αυτό στο φυσικό σύστημα είτε πρώτα το
μεταφράζει και μεταδίδει το μεταφρασμένο αν είναι υπερ-επόπτης τύπου 2. Έπειτα,
μπορεί να διαθέσει τους απαραίτητους για την εκτέλεση πόρους. Όλα αυτά
συμβαίνουν με σχεδόν εγγενή ταχύτητα αν γίνεται χρήση υπερ-επόπτη τύπου 1 όπου
δεν υπάρχει λειτουργικό σύστημα ανάμεσα στις εικονικές μηχανές και το φυσικό
μηχάνημα.

Εξαίρεση στον κανόνα απουσίας λειτουργικού συστήματος αποτελεί η χρήση ενός
υπερ-επόπτη ανοιχτού κώδικα βασισμένου στο KVM (Kernel-based Virtual Machine),
που επιτρέπει στο Linux να συμπεριφέρεται ως ένας υπερ-επόπτης. Αυτό συμβαίνει
διότι το KVM αποτελεί κομμάτι του πυρήνα του Linux από την έκδοση 2.6.20 και
έπειτα, επιτρέποντάς του να επωφεληθεί από τους διαθέσιμους μηχανισμούς
απομόνωσης μέσω αυτού. Επομένως, του προσφέρεται η ικανότητα να λάβει
αποκλειστικούς πόρους από το φυσικό μηχάνημα \cite{kvm}, κάτι που εξαλείφει το
μειονέκτημα έλλειψης προτεραιότητας των διεργασιών ενός υπερ-επόπτη τύπου 2
έναντι αυτών του λειτουργικού συστήματος φιλοξενίας.

\subsection{Είδη εικονικοποίησης} \label{virtualizationImplementations}

Υπάρχουν πολλά είδη εικονικοποίησης. Πέντε βασικά αυτών, όπως αναφέρονται από
την Red Hat \cite{redhatVirtualization}, συνδυαστικά με τρία ακόμα που
χρησιμοποιούνται συχνά είναι τα παρακάτω:

\begin{itemize}

    \item \textbf{Εικονικοποίηση Δεδομένων}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_data_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Δεδομένων \cite{redhatVirtualization}}
            \label{fig:dataVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

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

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Επιφάνειας Εργασίας}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/redhat_desktop_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Επιφάνειας Εργασίας \cite{redhatVirtualization}}
            \label{fig:desktopVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

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

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Διακομιστών}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/redhat_server_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Διακομιστών \cite{redhatVirtualization}}
            \label{fig:serverVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

Οι διακομιστές είναι υπολογιστές σχεδιασμένοι με σκοπό να επεξεργάζονται πολύ
καλά έναν μεγάλο όγκο συγκεκριμένων διεργασιών, ώστε οι κύριοι υπολογιστές μιας
επιχείρησης να μπορούν να δίνουν προτεραιότητα σε άλλες εργασίες. Με την
εικονικοποίηση διακομιστών αναφερόμαστε στην διαδικασία κατά την οποία ένας
φυσικός διακομιστής χωρίζεται σε πολλούς μικρότερους εικονικούς διακομιστές, με
απώτερο σκοπό την αποτελεσματικότερη αξιοποίηση των πόρων του. Αυτό είναι
απαραίτητο διότι προτιμάται για λόγους ευκολίας της διαχείρισής τους, κάθε
διακομιστής να είναι υπεύθυνος για μια μόνο διεργασία την φορά. Μετά την
κατάτμησή του, ενώ μπορεί να ακολουθείται η ίδια πρακτική, παύει το φυσικό
μηχάνημα να μένει με αχρησιμοποίητους πόρους και πρακτικά μπορεί το σύνολο τον
πόρων του να χρησιμοποιηθεί για την εξυπηρέτηση πολλαπλών λειτουργιών. Ο
ορισμός της εικονικοποίησης διακομιστών αναλύθηκε πιο λεπτομερώς και στο
\ref{virtualizationDefinition}.

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Λειτουργικού Συστήματος}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/redhat_os_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Λειτουργικού Συστήματος \cite{redhatVirtualization}}
            \label{fig:operatingSystemVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

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

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Λειτουργιών Δικτύου}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .7\textwidth]{Figures/RedHat_Virtualization/redhat_network_function_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Λειτουργιών Δικτύου \cite{redhatVirtualization}}
            \label{fig:networkFunctionVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

Η εικονικοποίηση λειτουργιών δικτύου (Network Functions Virtualization - NFV)
διαχωρίζει τις βασικές λειτουργίες ενός δικτύου (όπως ο διαμοιρασμός αρχείων,
και η διαμόρφωση IP), ώστε να μπορούν να διανεμηθούν σε διάφορα περιβάλλοντα.
Από τη στιγμή που οι λειτουργίες λογισμικού είναι ανεξάρτητες από τα φυσικά
μηχανήματα στα οποία εκτελούνται, συγκεκριμένες λειτουργίες μπορούν να
πακεταριστούν μαζί σε ένα νέο δίκτυο και να ανατεθούν σε ένα ξεχωριστό
περιβάλλον. Η εικονικοποίηση των δικτύων μειώνει τον αριθμό των φυσικών
εξαρτημάτων, όπως οι μεταγωγείς, δρομολογητές, διακομιστές, καλώδια και κόμβοι,
που απαιτούνται για τη δημιουργία πολλαπλών, ανεξάρτητων δικτύων και είναι
ιδιαίτερα δημοφιλής στον κλάδο των τηλεπικοινωνιών. Παραδοσιακά, οι λειτουργίες
δικτύου εκτελούνταν σε ιδιόκτητο υλικό συγκεκριμένου σκοπού και επομένως ήταν
απαραίτητο να πραγματοποιηθεί αγορά, ρύθμιση και συντήρηση του κάθε φυσικού
εξαρτήματος. Με την αύξηση όμως της δημοτικότητας των τεχνολογιών
εικονικοποίησης, άρχισε να γίνεται πιο δημοφιλής και η πρακτική πακεταρίσματος
των λειτουργιών των εξαρτημάτων αυτών σε διακομιστές κοινής χρήσης (commodity
servers). Το αποτέλεσμα αυτού, ήταν η απόκτηση της δυνατότητας εκτέλεσης των
λειτουργιών δικτύου μιας επιχείρησης σε τυπικούς διακομιστές γενικού σκοπού και
κατά προέκταση, η αντικατάσταση κάθε ξεχωριστού φυσικού μηχανήματος με ένα
αντίστοιχο εικονικό εκτελούμενο μέσα από μια εικονική μηχανή \cite{redhatNFV}.

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Μνήμης}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .8\textwidth]{Figures/VMWARE_Virtualization/vmware_memory_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Μνήμης \cite{vmwareMemoryVirtualization}}
            \label{fig:memoryVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

Η εικονικοποίηση μνήμης αποτελεί ένα κομμάτι της ευρύτερης έννοιας της
εικονικοποίησης πόρων \cite{hostitsmartMemoryVirtualization}. Συγκεκριμένα,
είναι μια τεχνική κατά την οποία δύναται να διαχειριστούμε με έναν πιο
αποδοτικό τρόπο την φυσική μνήμη (RAM) που χρησιμοποιείται στα υπολογιστικά μας
συστήματα. Αυτό συμβαίνει διότι στην βασικότερη μορφή της, η εικονικοποίηση
μνήμης εμφανίζεται ως εικονική μνήμη ή όπως η μνήμη swap σε διακομιστές και
σταθμούς εργασίας \cite{petriMemoryVirtualization}. Δηλαδή, ως επιπρόσθετη
μνήμη την οποία το σύστημα εκλαμβάνει ως πραγματική και μπορεί να την
χρησιμοποιήσει προτού αναγκαστεί να τερματίσει διεργασίες για να απελευθερώσει
κομμάτι της δικής του μνήμης. Για να επιτευχθεί αυτό, μέσω του υπερ-επόπτη
πραγματοποιείται αντιστοίχιση σελίδων φυσικής μνήμης του φιλοξενούμενου
λειτουργικού συστήματος στις σελίδες φυσικής μνήμης της υποκείμενης μηχανής.
Καθ' αυτόν τον τρόπο, κάθε εικονική μηχανή βλέπει έναν συνεχόμενο χώρο
διευθύνσεων μνήμης που δύναται να χρησιμοποιήσει
\cite{vmwareMemoryVirtualization}. Ως αποτέλεσμα, επιτυγχάνεται εν γένει
υψηλότερη αξιοποίηση της μνήμης και η δυνατότητα διαμοιρασμού μιας κοινής
δεξαμενής μνήμης ακόμα και σε κατανεμημένα συστήματα, παρακάμπτοντας τους
περιορισμούς της φυσικής μνήμης \cite{codingninjasMemoryVirtualization}.

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Αποθήκευσης}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .5\textwidth]{Figures/UnixArena_Virtualization/unixarena_storage_virtualization.png}
            \captionof{figure}{Εικονικοποίηση Αποθήκευσης \cite{unixarenaVirtualization}}
            \label{fig:storageVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

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

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

\clearpage

\begin{itemize}

    \item \textbf{Εικονικοποίηση Εφαρμογών}:

        \begin{center}
        \begin{figure}[!ht]
        \centering
            \includegraphics[width = .8\textwidth]{Figures/TutorialsPoint_Virtualization/tutorialspoint_application_virtualization.jpg}
            \captionof{figure}{Εικονικοποίηση Εφαρμογών \cite{tutorialsPointVirtualization}}
            \label{fig:applicationVirtualization}
        \end{figure}
        \vspace*{-30pt}
        \end{center}

\end{itemize}

Όπως και η εικονικοποίηση λειτουργικού συστήματος, έτσι και η εικονικοποίηση
εφαρμογών αποτελεί υποκατηγορία της εικονικοποίησης διακομιστών και υπάγεται
στην διαδικασία της δοχειοποίησης. Το επιθυμητό αποτέλεσμα της εικονικοποίησης
εφαρμογών είναι ο διαχωρισμός των βιβλιοθηκών και εξαρτήσεων τους από το
περιβάλλον στο οποίο εκτελούνται μέσω της δημιουργίας δοχείων. Στα δοχεία αυτά,
εικονικοποιούνται οι απαραίτητοι υπολογιστικοί πόροι όπως το λειτουργικό
σύστημα, η μνήμη και η κεντρική μονάδα επεξεργασίας
\cite{geeksforgeeksApplicationVirtualization}, κάνοντας χρήση των διαθέσιμων
μηχανισμών απομόνωσης του πυρήνα του λειτουργικού συστήματος. Περισσότερες
λεπτομέρειες για τον τρόπο κατά τον οποίο επιτυγχάνεται αυτό, παρουσιάζονται
στο \ref{osVirtualization}.

\clearpage

\subsection{Πλεονεκτήματα της εικονικοποίησης} \label{virtualizationAdvantages}

Η εικονικοποίηση προσφέρει πολλά πλεονεκτήματα στις επιχειρήσεις. Τα πιο
αξιοσημείωτα αυτών με βάση την \citeauthor{ibmVirtualizationDefinition}
\cite{ibmVirtualizationDefinition} είναι τα εξής:

\begin{itemize}

    \item \textbf{Αποδοτικότητα πόρων}:

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

    \item \textbf{Ευκολότερη διαχείριση}:

        Αντικαθιστώντας φυσικούς υπολογιστές με προγραμματιστικά καθορισμένες
        εικονικές μηχανές δύναται η χρήση αυτοματοποιημένων ροών διαχειριστικών
        εργασιών. Οι διαχειριστές συστημάτων μπορούν να χρησιμοποιούν εργαλεία
        για τον καθορισμό εικονικών μηχανών χρησιμοποιώντας πρότυπα κατάλληλα
        για την υποδομή κάθε επιχείρησης. Με αυτόν τον τρόπο, η εγκατάσταση και
        η ρύθμιση των εικονικών μηχανών μπορεί να γίνεται επανειλημμένα με
        αυτοματοποιημένο τρόπο δίχως το ρίσκο ανθρώπινου λάθους και γλιτώνοντας
        τον χρόνο εγκατάστασης και ρύθμισής τους χειροκίνητα. Ένας συνδυασμός
        εργαλείων που κάνει αυτή τη διαδικασία πραγματικότητα είναι τα Ansible
        \footfullcite{ansible} και Terraform \footfullcite{terraform}.

    \item \textbf{Ελάχιστος χρόνος διακοπής λειτουργίας}:

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

    \item \textbf{Ταχύτερη παροχή}:

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

\end{itemize}

\subsection{Παρα-εικονικοποίηση} \label{paraVirtualization}

Όταν αναφερόμαστε στην εικονικοποίηση συνήθως μιλάμε για την πιο συνηθισμένη
μορφή της, η οποία είναι η πλήρης εικονικοποίηση. Με την πάροδο του χρόνου και
την αύξηση της δημοτικότητας της εικονικοποίησης, αναπτύχθηκαν πολλοί
υπερ-επόπτες που μπορεί να διαφέρουν όχι μόνο στα χαρακτηριστικά τους αλλά και
στις διάφορες τεχνικές που χρησιμοποιούν για να κάνουν την εικονικοποίηση
πραγματικότητα. Μια από αυτές ονομάζεται παρα-εικονικοποίηση
(paravirtualization) \cite{suseParavirtualizationDefinition}.

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

Επομένως, η πλήρης εικονικοποίηση περιορίζει σημαντικά τον αριθμό των εικονικών
μηχανών που δύναται ένας διακομιστής να εκτελέσει παράλληλα, όπως επίσης και τα
είδη εφαρμογών που μπορούν να εκτελεστούν σε μια εικονική μηχανή (εφόσον η
ταχύτητα εκτέλεσης τους παίζει σημαντικό ρόλο στην ευχρηστία τους). Μερικοί
τομείς που επωφελούνται από την παρα-εικονικοποίηση είναι η χρήση λογισμικών
που επιτρέπουν την ανάκαμψη από καταστροφές, την μετανάστευση δεδομένων μεταξύ
λειτουργικών συστημάτων \cite{insightsForProfessionalsParavirtualization} ή
ακόμα και λογισμικά ενσωματωμένων συστημάτων αυτοκινήτων
\cite{blackberryParavirtualization}.

Η παρα-εικονικοποίηση είναι μια τεχνική εικονικοποίησης που αναπτύχθηκε
προκειμένου να ξεπεραστούν τα προαναφερόμενα προβλήματα επιδόσεων που έρχονται
με την χρήση της πλήρους εικονικοποίησης. Κατά την χρήση της, το φιλοξενούμενο
λειτουργικό σύστημα δεν είναι πλήρως απομονωμένο από το υλικό αλλά απομονώνεται
μερικώς \cite{serverWatchParavirtualization} και έχει άμεση επικοινωνία με
αυτό. Υπάρχει δηλαδή επίγνωση της εικονικοποίησης από μεριάς του ΛΣ των
εικονικών μηχανών και αξιοποίηση της, μέσω της χρήσης υπερ-κλήσεων προς τον
υπερ-επόπτη. Οι κλήσεις αυτές, επιτρέπουν σε κάθε ΛΣ να ζητάει πόρους κατά
παραγγελία και να αναθέτει την εκτέλεση διεργασιών του απευθείας στο υλικό. Για
να μπορέσει να επιτευχθεί αυτό, απαιτείται η τροποποίηση του φιλοξενούμενου
λειτουργικού συστήματος, η οποία θα του επιτρέπει την υλοποίηση ενός ειδικού
API, ώστε να μπορεί να κάνει χρήση των υπερ-κλήσεων
\cite{servermaniaParavirtualization}, ενώ επιβάλλεται να υποστηρίζεται και από
τον υπερ-επόπτη η κατανόησή τους.

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

Στο Σχήμα \ref{fig:FullVirtualization}
\cite{geeksforgeeksParavirtualizationDefinition} παρουσιάζεται η αρχιτεκτονική
της πλήρους εικονικοποίησης όπου το φιλοξενούμενο λειτουργικό σύστημα (της
εικονικής μηχανής) επιβάλλεται να περάσει τα αιτήματά του (πρόσβασης πόρων)
μέσω του υπερ-επόπτη.

\begin{center}
\begin{figure}[!ht]
\centering
    \includegraphics[width = .8\textwidth]{Figures/GeeksForGeeksParavirtualization/Full-Virualization.png}
    \captionof{figure}{Πλήρης εικονικοποίηση \cite{geeksforgeeksParavirtualizationDefinition}}
    \label{fig:FullVirtualization}
\end{figure}
\vspace*{-30pt}
\end{center}

\clearpage

Αντιθέτως, στο Σχήμα \ref{fig:ParaVirtualization} όπου και φαίνεται η
αρχιτεκτονική της παρα-εικονικοποίησης, βλέπουμε πως μέσω των υπερ-κλήσεων, όλα
τα αιτήματα προορίζονται στη στρώση εικονικοποίησης και από εκεί στο κύριο
σύστημα (χωρίς την ανάγκη κάποιας επεξεργασίας ή μετάφρασης).

\begin{center}
\begin{figure}[!ht]
\centering
    \includegraphics[width = .8\textwidth]{Figures/GeeksForGeeksParavirtualization/Paravirtualization.png}
    \captionof{figure}{Παρα-εικονικοποίηση \cite{geeksforgeeksParavirtualizationDefinition}}
    \label{fig:ParaVirtualization}
\end{figure}
\vspace*{-30pt}
\end{center}

\clearpage

\noindent Οι διαφορές της πλήρους εικονικοποίησης με την παρα-εικονικοποίηση με
βάση τον οργανισμό \citeauthor{geeksforgeeksParavirtualizationDefinition}
\cite{geeksforgeeksParavirtualizationDefinition} είναι οι εξής:

\begin{savenotes} % by the package footnote because footfullcite did not work inside a tabular
\selectfont
\begin{table}[!ht]
\caption{Διαφορές πλήρους εικονικοποίησης και παρα-εικονικοποίησης}
\renewcommand{\arraystretch}{1.5}
\centering
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
\textgreek{\begin{tabular}{||c|C|C||}
\hline

Νούμερο & Πλήρης εικονικοποίηση & Παρα-εικονικοποίηση \\ [0.5ex]

\hline\hline

1 &

Πλήρης απομόνωση της εικονικής μηχανής. &

Μερική απομόνωση και χρήση API για αμεσότερη επικοινωνία. \\

\hline

2 &

Λιγότερο ασφαλής. &

Υπάρχει επίγνωση του εικονικού περιβάλλοντος και δε γίνεται εκκίνηση του BIOS
\cite{ParavirtualizationSecurity}, πράγμα που την καθιστά ασφαλέστερη. \\

\hline

3 &

Χρήση δυαδικής μετάφρασης\footnote{\textgreek{Αυτό ισχύει στην περίπτωση
εικονικοποίησης υποβοηθούμενη από το λογισμικό.}}. &

Χρήση υπερ-κλήσεων κατά την εκτέλεση. \\

\hline

4 &

Πιο αργές ταχύτητες\footnote{\textgreek{Με βάση την VMware, η απόδοση της
παρα-εικονικοποίησης είναι καλύτερη υπό ορισμένες περιπτώσεις, ενώ η
πλήρης εικονικοποίηση με χρήση δυαδικής μετάφρασης παρέχει καλύτερη
απόδοση από την πρώτη γενιά εικονικοποίησης υποβοηθούμενη από το υλικό.}}
\cite{ParavirtualizationVmware}. &

Γρηγορότερη εκτέλεση. \\

\hline

5 &

Μεγαλύτερη συμβατότητα και μεταφερσιμότητα. &

Λόγω της αρχιτεκτονικής της είναι δυσκολότερη η μεταφορά εικονικών μηχανών (από
έναν φυσικό διακομιστή σε έναν άλλο) \\

\hline

6 &

Υποστήριξη όλων των συστημάτων χωρίς την απαίτηση τροποποιήσεων. &

Απαιτείται τροποποίηση του φιλοξενούμενου λειτουργικού συστήματος για να κάνει
χρήση υπερ-κλήσεων. \\

\hline
\end{tabular}}
\label{table:virtualizationTypesDifferences}
\renewcommand{\arraystretch}{1}
\end{table}
\end{savenotes}

\section{Ασφάλεια στην εικονικοποίηση} \label{virtualizationSecurity}

Η χρήση της εικονικοποίησης παρέχει αρκετά εγγενή οφέλη ασφαλείας με την μορφή
μέτρων ανάκαμψης από επιθέσεις. Ένα σημαντικό εξ αυτών, είναι η ικανότητα
επαναφοράς εικονικών μηχανών που έχουν μολυνθεί με κακόβουλο λογισμικό σε μια
χρονική περίοδο πριν τη μόλυνση τους. Αυτό επιτυγχάνεται μέσω της δυνατότητας
δημιουργίας στιγμιοτύπων εικονικών μηχανών \cite{vmSnapshots}, η οποία
παρέχεται από τον υπερ-επόπτη. Επιπρόσθετα, μπορεί εύκολα να πραγματοποιηθεί
διαγραφή και αναδημιουργία τους με έναν αυτοματοποιημένο τρόπο, σε περίπτωση
που η επαναφορά σε προηγούμενη χρονική περίοδο για οποιονδήποτε λόγο δεν είναι
εφικτή. Αυτή η λύση μπορεί να εφαρμοστεί χωρίς αρνητικές επιπτώσεις εάν τα
δεδομένα της εικονικής μηχανής είτε δεν μας ενδιαφέρουν, είτε βρίσκονται σε
διαφορετική τοποθεσία επειδή γίνεται χρήση εικονικοποίησης αποθήκευσης, είτε
υπάρχουν αντίγραφα ασφαλείας τους. Αυτές οι λειτουργίες είναι αρκετές φορές
αδύνατο να εφαρμοστούν σε ένα φυσικό μηχάνημα διότι το κακόβουλο λογισμικό
συχνά μπορεί να είναι βαθιά ριζωμένο στα βασικά συστατικά του συστήματος
\cite{ibmVirtualizationDefinition}. Επιπλέον, ακόμα και αν το κακόβουλο
λογισμικό ήταν σε θέση να εξαφανιστεί με μια επαναφορά, κάτι τέτοιο θα
χρειαζόταν σημαντικά περισσότερο χρόνο για να διεκπεραιωθεί σε ένα φυσικό
μηχάνημα συγκριτικά με μια εικονική μηχανή.

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

\subsection{Απειλές στην εικονικοποίηση} \label{virtualizationThreats}

Όλες οι μορφές εικονικοποίησης είναι ευάλωτες σε επιθέσεις. Όπως αναφέρεται και
στο \cite{wen2008sevmm} μέσω του \cite{arif2015virtualization}, πολλές φορές δε
δύναται ο υπερ-επόπτης, το λειτουργικό σύστημα ή ακόμα και η υπηρεσία ελέγχου
πρόσβασης (Mandatory Access Control) του Linux να ανταπεξέλθουν στις απαιτήσεις
ασφαλείας όλων των εφαρμογών. Το παράδειγμα που παρουσιάζεται στο
\cite{arif2015virtualization} αναφέρεται στην εικονικοποίηση χώρου αποθήκευσης
μέσω δικτύου αλλά πολλές από τις απειλές δεν περιορίζονται μονάχα εκεί.

\clearpage

\noindent Πολλές από τις απειλές που θα αναφερθούν παρακάτω στο
\ref{virtualizationThreatsCategorization}, μπορούν να κατηγοριοποιηθούν και ως
εξής:

\begin{table}[!ht]
\caption{Πηγές απειλών στην εικονικοποίηση}
\renewcommand{\arraystretch}{1.5}
\centering
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
\textgreek{\begin{tabular}{||C|C||}
\hline

Πηγή απειλής & Περιγραφή \\ [0.5ex]

\hline\hline

Δίκτυο $\Rightarrow$ Υπερ-επόπτη &

Απειλές που προέρχονται από το δίκτυο και στοχεύουν τον υπερ-επόπτη. \\

\hline

Δίκτυο $\Rightarrow$ Εικονική Μηχανή &

Απειλές που προέρχονται από το δίκτυο και στοχεύουν εικονικές μηχανές. \\

\hline

Υπερ-επόπτη $\Rightarrow$ Εικονική Μηχανή &

Απειλές που προέρχονται από τον υπερ-επόπτη και στοχεύουν εικονικές μηχανές. \\

\hline

Εικονική μηχανή $\Rightarrow$ Εικονική Μηχανή &

Απειλές που προέρχονται από εικονικές μηχανές και στοχεύουν άλλες εικονικές
μηχανές. \\

\hline

Εικονική μηχανή $\Rightarrow$ Υπερ-επόπτη &

Απειλές που προέρχονται από εικονικές μηχανές και στοχεύουν τον υπερ-επόπτη. \\

\hline

Διαχειριστή $\Rightarrow$ Υπερ-επόπτη &

Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν τον
υπερ-επόπτη. \\

\hline

Διαχειριστή $\Rightarrow$ Εικονική Μηχανή &

Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν
εικονικές μηχανές. \\

\hline
\end{tabular}}
\label{table:virtualizationThreatSources}
\renewcommand{\arraystretch}{1}
\end{table}

\subsubsection{Απειλές για τον πάροχο νέφους μέσω δικτύου} \label{cloudProviderThreatsOverNetwork}

Σήμερα όλο και περισσότερες επιχειρήσεις θα προτιμήσουν να βασιστούν σε έναν
πάροχο νέφους για την απόκτηση υποδομών προκειμένου να εξυπηρετούν τους
δυνητικούς πελάτες τους έναντι της παραδοσιακής διαδικασίας αγοράς, ρύθμισης
και διαχείρισης φυσικών διακομιστών. Η ταχύτερη εκκίνηση παροχής υπηρεσιών, το
μικρότερο κόστος και η ευκολία διαχείρισης της υποδομής τους, δεν αφήνουν
περιθώρια αμφιβολίας της ορθότητας αυτής της απόφασης. Για να μπορούν όμως να
παρέχουν τις υπηρεσίες τους στους τελικούς χρήστες, είναι απαραίτητη η μεταφορά
δεδομένων από την επιχείρηση προς τον πάροχο νέφους, στις υποδομές του οποίου
στεγάζονται οι εφαρμογές τους. Όπως αναφέραμε όμως στο
\ref{cloudComputingSecurity}, εισάγεται έτσι ένα αναγκαίο μοντέλο εμπιστοσύνης
ανάμεσα στον πάροχο νέφους και τις επιχειρήσεις. Δηλαδή, ταυτόχρονη εμπιστοσύνη
ως προς την απουσία μη εξουσιοδοτημένης πρόσβασης στα δεδομένα των επιχειρήσεων
από τον πάροχο και ως προς την ικανότητα του παρόχου να λάβει τα απαραίτητα
μέτρα ασφαλείας για την προστασία τους από εξωτερικούς κακόβουλους χρήστες.

Ένα από τα σημαντικότερα ζητήματα που απασχολεί μια επιχείρηση είναι η
ασφάλεια. Επιλέγοντας να χρησιμοποιήσουν τις υπηρεσίες ενός παρόχου νέφους,
όμως, παραχωρούν ουσιαστικά πρόσβαση στον πάροχο αυτό στις εφαρμογές τους και
στα ευαίσθητα δεδομένα αυτών των εφαρμογών, διότι η ευθύνη προστασίας των
υποδομών ανήκει στον ιδιοκτήτη των υποδομών αυτών και στην προκειμένη περίπτωση
αυτός είναι ο πάροχος νέφους. Έτσι, κακόβουλοι εισβολείς θα προσπαθήσουν να
βρουν τρωτότητες στη διαδικασία παράδοσης των υπηρεσιών του παρόχου, στις
υπηρεσίες τις ίδιες ή και στις διεπαφές με τις οποίες παρέχονται. Ένας
συνηθισμένος τρόπος για να γίνει αυτό είναι εκτελώντας επιθέσεις τύπου
Cross-site scripting (XSS), έγχυσης SQL (SQL injection), χειραγώγησης cookies ή
εκμετάλλευσης μη ασφαλούς ρύθμισης, θέτοντας έτσι σε κίνδυνο ευαίσθητες
πληροφορίες και δεδομένα των επιχειρήσεων. Επιπλέον, επειδή όλα τα δίκτυα είναι
επιρρεπή σε επιθέσεις αν δεν έχουν ληφθεί τα κατάλληλα μέτρα προστασίας, ένας
πάροχος πρέπει να μπορεί να προστατευτεί από επιθέσεις, όπως η κατασκοπεία και
διείσδυση δικτύου (network penetration) \cite{arif2015virtualization}.

\subsubsection{Απειλές για τον πάροχο νέφους μέσω εικονικών μηχανών} \label{cloudProviderAttackOverVMs}

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

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

Με βάση την ανάλυση που έγινε στο \cite{virtualizationSecurity}, σχετικά με
απειλές από εικονική μηχανή σε εικονική μηχανή, οι πιο συνηθισμένες είναι η
επίθεση πλευρικού καναλιού (cross VM side channel attack), οι επιθέσεις βάσει
χρονοπρογραμματιστή (Scheduler based attacks) και οι επιθέσεις που στοχεύουν
τρωτότητες της διαδικασίας μετανάστευσης και επαναφοράς εικονικών μηχανών (VM
migration and rollback attacks). Από την άλλη, όσον αφορά τις απειλές από
εικονικές μηχανές προς τον υπερ-επόπτη, ανάμεσα στις πιο σημαντικές βρίσκονται
η μεταπήδηση εικονικής μηχανής (VM Hopping) και η απόδραση εικονικής μηχανής
(VM Escape). Τέλος, μερικές επιπρόσθετες απειλές σύμφωνα με τους
\citeauthor{Aalam_2021} \cite{Aalam_2021}, είναι η κλοπή εικονικών μηχανών και
η τροποποίηση του υπερ-επόπτη.

\clearpage

\subsubsection{Κατηγοριοποίηση απειλών στην εικονικοποίηση} \label{virtualizationThreatsCategorization}

Οι προαναφερόμενες απειλές σε συνδυασμό με μερικές πιθανές ευπάθειες, έχουν
κατηγοριοποιηθεί από τους \citeauthor{virtualizationSecurity} στο
\cite{virtualizationSecurity} ως εξής:

\begin{table}[!ht]
\caption{Κατηγοριοποίηση απειλών στην εικονικοποίηση}
\renewcommand{\arraystretch}{1.3}
\aboverulesep=-0.1ex
\belowrulesep=-0.1ex
\centering
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
\textgreek{\begin{tabular}{||C|C||}
\hline
                       Κατηγορία                 & Απειλές και πιθανά ευπαθή σημεία  \\ \hline\hline
\multirow{11}{*}{\hfil Απειλές Δικτύου}          & XML Signature Wrapping Attacks    \\ \cmidrule(lr){2-2}
                                                 & Flooding Attacks (DDoS)           \\ \cmidrule(lr){2-2}
                                                 & Metadata Spoofing Attacks         \\ \cmidrule(lr){2-2}
                                                 & Insecure Web Apps \& APIs         \\ \cmidrule(lr){2-2}
                                                 & Cross Site Scripting Attacks      \\ \cmidrule(lr){2-2}
                                                 & Port scanning                     \\ \cmidrule(lr){2-2}
                                                 & Botnets                           \\ \cmidrule(lr){2-2}
                                                 & Spoofing attacks                  \\ \cmidrule(lr){2-2}
                                                 & DNS attacks                       \\ \cmidrule(lr){2-2}
                                                 & Sniffer attacks                   \\ \cmidrule(lr){2-2}
                                                 & Denial of Service (DoS)           \\ \hline
\multirow{9}{*}{\hfil Απειλές για τον Πάροχο}    & Sniffing Attacks                  \\ \cmidrule(lr){2-2}
                                                 & Spoofing Attacks                  \\ \cmidrule(lr){2-2}
                                                 & Denial of Service Attacks         \\ \cmidrule(lr){2-2}
                                                 & cross VM side channel attacks     \\ \cmidrule(lr){2-2}
                                                 & VM scheduler based attacks        \\ \cmidrule(lr){2-2}
                                                 & VM Hopping                        \\ \cmidrule(lr){2-2}
                                                 & VM Escape                         \\ \cmidrule(lr){2-2}
                                                 & Dynamic Data Updates              \\ \cmidrule(lr){2-2}
                                                 & Data scavenging                   \\ \hline
\multirow{6}{*}{\hfil Απειλές για τις Εφαρμογές} & Malware injection                 \\ \cmidrule(lr){2-2}
                                                 & Steganography attacks             \\ \cmidrule(lr){2-2}
                                                 & Web services attacks              \\ \cmidrule(lr){2-2}
                                                 & Protocol-based attacks            \\ \cmidrule(lr){2-2}
                                                 & Security Misconfigurations        \\ \cmidrule(lr){2-2}
                                                 & SQL Injection Attacks             \\ \hline
\end{tabular}}
\label{table:virtualizationThreatCategories}
\renewcommand{\arraystretch}{1}
\end{table}

% Same result but with 23 warning about wrong hline usage
% \begin{table}[!ht]
% \caption{Κατηγοριοποίηση απειλών στην εικονικοποίηση}
% \renewcommand{\arraystretch}{1.5}
% \centering
% \newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
% \newcommand\Tstrut{\rule{0pt}{2.6ex}}         % = `top' strut
% \newcommand\Bstrut{\rule[-0.9ex]{0pt}{0pt}}   % = `bottom' strut
% \textgreek{\begin{tabular}{||C|C||}
% \hline
% %
% Κατηγορία & Απειλές και πιθανά ευπαθή σημεία \\ [0.5ex]
% %
% \hline\hline
% %
% Απειλές Δικτύου &
% %
% XML Signature Wrapping Attacks\Tstrut\Bstrut\hline
% Flooding Attacks (DDoS)\Tstrut\Bstrut\hline
% Metadata Spoofing Attacks\Tstrut\Bstrut\hline
% Insecure Web Apps \& APIs\Tstrut\Bstrut\hline
% Cross Site Scripting Attacks\Tstrut\Bstrut\hline
% Port scanning\Tstrut\Bstrut\hline
% Botnets\Tstrut\Bstrut\hline
% Spoofing attacks\Tstrut\Bstrut\hline
% DNS attacks\Tstrut\Bstrut\hline
% Sniffer attacks\Tstrut\Bstrut\hline
% Denial of Service (DoS)\Tstrut\Bstrut \\
% %
% \hline
% %
% Απειλές για τον Πάροχο &
% %
% Sniffing Attacks\Tstrut\Bstrut\hline
% Spoofing Attacks\Tstrut\Bstrut\hline
% Denial of Service Attacks\Tstrut\Bstrut\hline
% cross VM side channel attacks\Tstrut\Bstrut\hline
% VM scheduler based attacks\Tstrut\Bstrut\hline
% VM Hopping\Tstrut\Bstrut\hline
% VM Escape\Tstrut\Bstrut\hline
% Dynamic Data Updates\Tstrut\Bstrut\hline
% Data scavenging\Tstrut\Bstrut \\
% %
% \hline
% %
% Απειλές για τις Εφαρμογές &
% %
% Malware injection\Tstrut\Bstrut\hline
% Steganography attacks\Tstrut\Bstrut\hline
% Web services attacks\Tstrut\Bstrut\hline
% Protocol-based attacks\Tstrut\Bstrut\hline
% Security Misconfigurations\Tstrut\Bstrut\hline
% SQL Injection Attacks\Tstrut\Bstrut \\
% %
% \hline
% \end{tabular}}
% \label{table:virtualizationThreatCategories}
% \renewcommand{\arraystretch}{1}
% \end{table}

\clearpage

Κατηγοριοποίηση με μεγαλύτερη λεπτομέρεια ως προς τις κατηγορίες αδυναμιών όπου
δύναται να υπάρχουν τρωτότητες και τις αντιστοιχούμενες αδυναμίες αυτών,
πραγματοποιήθηκε από τον οργανισμό \citeauthor{enisaSecurityOfVirtualization}
στο \cite{enisaSecurityOfVirtualization} όπου και απεικονίζεται στο ακόλουθο
σχήμα:

\begin{center}
    \begin{figure}[!ht]
        \centering
        \includegraphics[width = .91\textwidth]{Figures/Enisa/enisaThreats.jpg}
        \captionof{figure}{Πιθανά σημεία εμφάνισης τρωτοτήτων και οι απειλές που τους αντιστοιχούν}
        \label{fig:virtualizationThreats.png}
    \end{figure}
\vspace*{-30pt}
\end{center}

\subsection{Η τριάδα της ασφάλειας} \label{securityTriad}

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

\begin{itemize}

    \item \textbf{Ακεραιότητα δεδομένων} \label{dataIntegrity}

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

    \item \textbf{Εμπιστευτικότητα δεδομένων} \label{dataConfidentiality}

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

    \item \textbf{Διαθεσιμότητα δεδομένων} \label{dataAvailability}

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

\end{itemize}

\subsection{Μέτρα ασφαλείας} \label{securityMeasures}

Προκειμένου να προστατευτεί μια επιχείρηση από τις απειλές που αναφέρθηκαν
παραπάνω, θα πρέπει αυτή να έχει λάβει τα κατάλληλα μέτρα ασφαλείας. Μερικές
ορθές πρακτικές με βάση τους οργανισμούς
\citeauthor{geeksforgeeksVirtualizationSecurityGoodPractices}
\cite{geeksforgeeksVirtualizationSecurityGoodPractices} και
\citeauthor{enisaSecurityOfVirtualization} \cite{enisaSecurityOfVirtualization}
είναι οι παρακάτω:

\begin{itemize}

    \item \textbf{Συχνή ενημέρωση του υπερ-επόπτη}:

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

    \item \textbf{Περιορισμός πρόσβασης στο διαχειριστικό πάνελ του υπερ-επόπτη}:

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

    \item \textbf{Έλεγχος των μηχανημάτων που έχουν πρόσβαση στον υπερ-επόπτη}:

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

\clearpage

    \item \textbf{Περιορισμός δικτυακής πρόσβασης στο διαχειριστικό πάνελ του υπερ-επόπτη}:

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

    \item \textbf{Χρήση κρυπτογράφησης εικονικών μηχανών}:

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

    \item \textbf{Απομόνωση των εικονικών μηχανών μεταξύ τους}:

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

    \item \textbf{Παρακολούθηση των πόρων}:

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

    \item \textbf{Ορθή διαχείριση στιγμιοτύπων εικονικών μηχανών}:

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

\clearpage

    \item \textbf{Ασφάλιση του μηχανήματος φιλοξενίας}:

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

\end{itemize}

\section{Δοχεία και εικόνες δοχείων} \label{containersAndContainerImages}

Τα δοχεία αποτελούν και αυτά κομμάτι των τεχνολογιών εικονικοποίησης αλλά σε
επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
(containerization). Σε αντίθεση με τις τεχνολογίες εικονικοποίησης που
αναφέρθηκαν στην Ενότητα \ref{virtualizationTechnologiesIntroduction}, για την
δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
αναλαμβάνει η μηχανή δοχείων. Επιπλέον, ενώ οι εικονικές μηχανές καταλήγουν να
περιέχουν εικονικό αντίγραφο του υλικού, δικό τους λειτουργικό σύστημα και
εγκατεστημένα πακέτα προς υποστήριξη ενός λογισμικού, τα δοχεία αποτελούνται
μονάχα από το λογισμικό προς εκτέλεση και τις εξαρτήσεις (βιβλιοθήκες και
προγράμματα) που χρειάζεται προκειμένου αυτό να είναι λειτουργικό.

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

Ορισμένα από αυτά τα βήματα περιλαμβάνουν και άλλες διαδικασίες για τις οποίες
είναι υπεύθυνα συγκεκριμένα προγράμματα με τα οποία συνεργάζεται η μηχανή
δοχείων. Υπάρχουν και μηχανές δοχείων χαμηλού επιπέδου έναντι των πιο γνωστών
υψηλού επιπέδου όπως το Docker, στις οποίες λείπουν ορισμένες λειτουργίες, όπως
η απόκτηση εικόνων δοχείων από ένα κεντρικό αποθετήριο και ο έλεγχος
εγκυρότητας των ρυθμίσεων των εικόνων αυτών. Οι μηχανές δοχείων υψηλού επιπέδου
είναι ουσιαστικά μια συλλογή εργαλείων που διευκολύνουν την δοχειοποίηση
απαλλάσσοντας τον χρήστη από την ανάγκη της χειροκίνητης εκτέλεσης των βημάτων
της \cite{sysdigContainerRuntime}.

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

\subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}

Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux,
διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
(λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών,
καθώς και οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την
δυνατότητα περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα
αρχείων. Με την βοήθεια των εργαλείων που έχουν οι μηχανές δοχείων στην διάθεσή
τους, δύναται να πραγματοποιηθεί εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος
εικονικοποίησης διακομιστών όπου ο πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη
πολλαπλών απομονωμένων περιβαλλόντων \cite{teimouriOsVirtualizationDefinition},
τα οποία συμπεριφέρονται ως ξεχωριστοί διακομιστές
\cite{webopediaOsVirtualizationDefinition}.

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

\section{Δοχειοποίηση (Containerization)} \label{containerizationDefinition}

Πέραν της πλήρους εικονικοποίησης και της παρα-εικονικοποίησης, εδώ και αρκετά
χρόνια πολλές επιχειρήσεις στρέφονται σε τεχνολογίες που χρησιμοποιούν μια
υποκατηγορία της εικονικοποίησης, ονόματι δοχειοποίηση (containerization). Με
βάση την \citeauthor{ibmContainerizationDefinition}
\cite{ibmContainerizationDefinition}, πρόκειται για το πακετάρισμα λογισμικού
μονάχα με τις βιβλιοθήκες και τις εξαρτήσεις που χρειάζεται για να εκτελεστεί,
δημιουργώντας ένα εκτελέσιμο \textquote{δοχείο} που πάντοτε θα εκτελείται με
την ίδια συμπεριφορά ανεξαρτήτως υποδομής. Με την παραδοσιακή μέθοδο ανάπτυξης
λογισμικού, υπήρχε πάντα το ρίσκο το πρόγραμμα που αναπτύχθηκε σε ένα
συγκεκριμένο περιβάλλον να μη λειτουργεί με τον αναμενόμενο τρόπο κατά τη
μεταφορά του σε ένα άλλο, εκτός εάν έχει ελεγχθεί ότι υπάρχουν όλες οι
εξαρτήσεις που χρειάζεται στις εκδόσεις που τις χρειάζεται. Ακόμα και σε αυτήν
την περίπτωση όμως, πέραν του κόπου για τον έλεγχο, είναι αρκετά πιθανό ένα
άλλο πρόγραμμα να χρειάζεται διαφορετικές εκδόσεις των ίδιων εξαρτήσεων. Αυτό
πρακτικά σήμαινε πως το έτερο αυτό πρόγραμμα θα έπρεπε να στεγαστεί σε
διαφορετικό διακομιστή, αυξάνοντας το σχετικό κόστος.

Τα προβλήματα αυτά έρχεται να λύσει η τεχνολογία της δοχειοποίησης. Με τη
δοχειοποίηση, είναι δυνατή η συστέγαση δοχείων, δηλ. διαφορετικών προγραμμάτων
ή συστατικών προγραμμάτων στο ίδιο μηχάνημα (είτε αυτό είναι φυσικό είτε
εικονικό). Όπως θα αναφέρουμε και στην Ενότητα \ref{containerManagement}, από
το 2013 και έπειτα, η άφιξη του Docker επιτάχυνε κατά πολύ την υιοθέτηση της
τεχνολογίας αυτής. Σε τέτοιο βαθμό που σε μια έρευνα της IBM
\cite{ibmContainerSurvey} βρέθηκε πως το 61\% όσων ξεκίνησαν να χρησιμοποιούν
δοχεία, το κάνουν στο 50\% ή παραπάνω των εφαρμογών που δημιούργησαν τα
τελευταία δύο χρόνια, ενώ 64\% αυτών, αναμένουν στο 50\% των υπαρχουσών
εφαρμογών τους να κάνουν χρήση δοχείων στα επόμενα δύο χρόνια.

Ένας από τους χαρακτηρισμούς των δοχείων είναι η \textquote{ελαφρότητα} τους σε
σχέση με μια εικονική μηχανή λόγω της ικανότητας τους να μοιράζονται τον πυρήνα
του ίδιου λειτουργικού συστήματος (ΛΣ). Η απαίτηση μιας εικονικής μηχανής να
χρειάζεται να έχει δικό της ΛΣ, την καθιστά μεγαλύτερη σε μέγεθος και λιγότερο
αποδοτική στη χρήση πόρων του συστήματος. Απεναντίας, τα δοχεία είναι εγγενώς
μικρότερα σε μέγεθος και έχουν και μικρότερο χρόνο εκκίνησης. Πράγμα που
τραβάει το ενδιαφέρον των επιχειρήσεων διότι αυτό μεταφράζεται σε υψηλότερη
αποδοτικότητα \& βαθμό χρήσης των διακομιστών και επομένως μειωμένα κόστη
λειτουργίας. Επίσης, τα δοχεία κλιμακώνονται αρκετά πιο γρήγορα σε σχέση με τις
εικονικές μηχανές, επιτρέποντας την αντίδραση σε οποιαδήποτε διακύμανση του
φόρτου εργασίας.

\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,
το Docker αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την
δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα,
τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
(φιλοξενίας), παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων
δοχείων, όπως είναι το 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 - CD) όπου τα εκτελέσιμα πακέτα των εφαρμογών
διατάσσονται σε περιβάλλοντα παραγωγής και γίνονται άμεσα διαθέσιμα προς
απομακρυσμένη κατανάλωση από τους πελάτες τους.

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

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

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

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

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

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

\subsection{Δοχειοποίηση Εφαρμογών (Application Containerization)} \label{applicationContainerization}

Τα δοχεία ενθυλακώνουν ένα λογισμικό ή ένα συστατικό (component) εφαρμογής ως
ένα αυτόνομο πακέτο που περιέχει τον κώδικα, τις βιβλιοθήκες και τις εξαρτήσεις
που χρειάζεται για να εκτελεστεί. Οι διεργασίες ενός δοχείου θεωρούνται
απομονωμένες με την έννοια ότι δεν έχουν ανάγκη για ένα αντίγραφο του
λειτουργικού συστήματος αλλά αντ' αυτού μιας μηχανής εκτέλεσης δοχείων
(container execution engine) στο μηχάνημα (φιλοξενίας) που λειτουργεί ως
διαμεσολαβητής των δοχείων για να μοιράζονται το ίδιο λειτουργικό σύστημα και
κατά προέκταση τους υποκείμενους πόρους του μεταξύ τους. Κοινές βιβλιοθήκες ή
εκτελέσιμα αρχεία μιας στρώσης εικόνας δοχείων μπορούν επίσης να
χρησιμοποιηθούν για την δημιουργία πολλών δοχείων, συμβάλλοντας έτσι στην
εξάλειψη περιττής υπολογιστικής ισχύος, καθιστώντας τα δοχεία μικρά στον χώρο
που καταλαμβάνουν, γρήγορα στην εκκίνηση και ικανά να εκτελεστούν σε
οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους \cite{ibmContainerizationDefinition}.

Η δοχειοποίηση εφαρμογών αποτελεί εν γένει την πιο δημοφιλή μορφή δοχειοποίησης
που χρησιμοποιείται σήμερα. Είθισται να χρησιμοποιείται σε περιπτώσεις χρήσης
μικρο-υπηρεσιών, CI/CD pipelines, επαναλαμβανόμενων διεργασιών και εφαρμογής
μεθόδων DevOps \cite{applicationContainerization}.

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

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

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

\noindent Το Σχήμα \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 \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
όπως το Docker Compose.

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

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

\clearpage

Τα δοχεία προσφέρουν μια σειρά από πλεονεκτήματα σε σχέση με τις παραδοσιακές
εικονικές μηχανές. Αυτά, σύμφωνα με την
\citeauthor{ibmContainerizationDefinition}
\cite{ibmContainerizationDefinition}, μπορούν να συνοψιστούν ως εξής:

\begin{itemize}

    \item \textbf{Mεταφερσιμότητα}:

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

    \item \textbf{Ευελιξία}:

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

    \item \textbf{Ταχύτητα}:

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

    \item \textbf{Απομόνωση σφαλμάτων}:

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

\clearpage

    \item \textbf{Μέγιστη χρηστικότητα πόρων}:

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

    \item \textbf{Ευκολία διαχείρισης}:

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

    \item \textbf{Ασφάλεια}:

        Η απομόνωση των εφαρμογών ως δοχεία, όταν εφαρμόζεται ακολουθώντας
        ορθές πρακτικές, εγγενώς αποτρέπει την εισβολή κακόβουλου λογισμικού
        από το να επηρεάσει τα υπόλοιπα δοχεία ή το σύστημα στο οποίο
        εκτελούνται. Συγκεκριμένα, χρησιμοποιώντας Kernel Security Modules,
        όπως είναι το AppArmor ή το SELinux, μπορούν να ορισθούν άδειες
        ασφαλείας με σκοπό τον περιορισμό του εύρους πρόσβασης του Docker στο
        σύστημα, ενώ με access authorization plugins
        \cite{accessAuthorizationPlugin}, περιορίζεται η πρόσβαση στον δαίμονα
        του Docker. Επιπροσθέτως, πολύ εύκολα μπορεί να περιοριστεί και η
        επικοινωνία μεταξύ δοχείων, καθώς και με το δίκτυο του συστήματος.

\end{itemize}

\subsection{Διαφορές σε υλοποιήσεις της δοχειοποίησης} \label{containerizationImplementationDifferences}

Στην Ενότητα \ref{containerizationDefinition} αναφέραμε την έννοια της
δοχειοποίησης. Η ραγδαία αύξηση του ενδιαφέροντος και της χρήσης δοχείων
οδήγησε στην ανάγκη για πρότυπα γύρω από την τεχνολογία αυτή. Έτσι, η Open
Container Initiative (OCI), η οποία ιδρύθηκε τον Ιούνιο του 2015 από την Docker
και άλλους ηγέτες του κλάδου, προωθεί κοινά, ανοικτά πρότυπα και προδιαγραφές
γύρω από την τεχνολογία δοχείων. Εξαιτίας αυτού, η OCI συμβάλλει στη διεύρυνση
των επιλογών για μηχανές δοχείων ανοιχτού κώδικα και συνεπώς, οι χρήστες δε θα
είναι εγκλωβισμένοι στην τεχνολογία ενός συγκεκριμένου προμηθευτή. Απεναντίας,
θα μπορούν να επωφεληθούν από τις πιστοποιημένες από την OCI τεχνολογίες που θα
τους επιτρέπουν να δημιουργούν εφαρμογές σε δοχεία χρησιμοποιώντας ένα ευρύ
σύνολο εργαλείων DevOps, τις οποίες θα μπορούν να εκτελούν με τον ίδιο τρόπο σε
οποιεσδήποτε υποδομές της επιλογής τους.

Σήμερα, αν και το Docker αποτελεί μία από τις πιο γνωστές και ευρέως
χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες εναλλακτικές
υλοποιήσεις. Για παράδειγμα, το Podman \cite{podman} είναι μια γνωστή
εναλλακτική μηχανή δοχείων ενώ το LXC και το containerd είναι εναλλακτικά
container runtimes - μάλιστα το τελευταίο ήταν για καιρό η προεπιλογή του
Docker για container runtime προτού υιοθετήσει το runC. Οι προαναφερόμενες
εναλλακτικές υλοποιήσεις μπορεί να έχουν διαφορετικά χαρακτηριστικά και
προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση των προδιαγραφών της OCI καθώς
αυτές εξελίσσονται θα διασφαλίσει ότι οι εναλλακτικές αυτές παραμένουν
ανεξάρτητες από τους προμηθευτές, πιστοποιημένες για να τρέχουν σε πολλαπλά
λειτουργικά συστήματα και χρησιμοποιήσιμες σε πολλαπλά περιβάλλοντα
\cite{ibmContainerizationDefinition}.

Παρότι οι προδιαγραφές της OCI έχουν ως στόχο να διασφαλίσουν την ομοιόμορφη
λειτουργία της τεχνολογίας αυτής, υπάρχουν αρκετές διαφορές στην υλοποίηση της.
Παραδείγματος χάριν, το Podman, ενώ συμμορφώνεται στις προδιαγραφές της OCI
όπως το Docker, δουλεύει χωρίς δαίμονα από πίσω, πράγμα που επιδιώκει να
κατευνάσει τις ανησυχίες γύρω από τον τρόπο λειτουργίας του Docker. Αυτό
συμβαίνει διότι το Docker χρειάζεται διαχειριστικές άδειες για την λειτουργία
του δαίμονα του, γεγονός που αφήνει το σύστημα ευάλωτο σε επιθέσεις σε
περίπτωση που αυτός παραβιαστεί. Παρότι και οι δύο αυτές μηχανές δοχείων
χρησιμοποιούν το runC ως container runtime, το Podman χρησιμοποιεί το systemd
για την διαχείριση των δοχείων του, το οποίο μπορεί να χρησιμοποιηθεί από
χρήστες χωρίς διαχειριστικές άδειες. Συνεπώς, εξαιτίας του τρόπου λειτουργίας
του, αν και από το 2021, χάρη στη δουλειά του Akihiro Suda
\footfullcite{AkihiroSuda}, η αποφυγή χρήσης δαίμονα δεν ισχύει μόνο για αυτό
πλέον, το Podman δύναται να εκτελεστεί από έναν χρήστη πέραν του
διαχειριστή/ριζικού (root).

Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το Podman είναι το rkt
\footfullcite{rkt} το οποίο προσπαθούσε να κρατήσει μια προσέγγιση ασφαλούς
σχεδιασμού εξ αρχής (Secure-by-design). Μπορούσε να ενσωματώσει χαρακτηριστικά
ασφαλείας, όπως υποστήριξη SELinux, TPM measurement και εκτέλεση δοχείων σε
απομονωμένες από το υλικό εικονικές μηχανές. Παρ' όλα αυτά, σύμφωνα με τον
\citeauthor{dockerAlternatives} \cite{dockerAlternatives}, έπαψε να έχει ενεργή
ανάπτυξη και επομένως δεν θα συνεχίζει να ανταγωνίζεται παρόμοια εργαλεία στον
κλάδο των δοχείων.

Στην Ενότητα \ref{virtualizationImplementations} αναφέραμε την εικονικοποίηση
λειτουργικού συστήματος και στην \ref{containerManagement} το LXC. Αποτελεί και
αυτό ένα container runtime, με την διαφορά ότι αντί να επικεντρώνεται στην
δοχειοποίηση εφαρμογών, όπως κάνει το Docker χρησιμοποιώντας το runC, ο κύριος
σκοπός της δημιουργίας του ήταν η δοχειοποίηση λειτουργικών συστημάτων. Αν και
χρησιμοποιείται ακόμα στις μέρες μας, η δημοτικότητα του έχει πέσει από τότε
που το ενδιαφέρον τον επιχειρήσεων στράφηκε στην δοχειοποίηση εφαρμογών, με
αποτέλεσμα την ανάγκη δημιουργίας εργαλείων που να διευκολύνουν την διαδικασία
αυτή, η οποία οδήγησε στην δημιουργία του Docker.

Σχετικά με τα container runtimes runC και containerd, το πρώτο είναι ένα
container runtime χαμηλού επιπέδου ενώ το δεύτερο υψηλού επιπέδου.
Δημιουργήθηκαν και τα δύο από το Docker σε διαφορετικές χρονικές περιόδους. Από
τις αρχικές του εκδόσεις, το Docker χρησιμοποιούσε το containerd από
προεπιλογή. Μετέπειτα, αποφάσισε να το καταστήσει ένα αυτόνομο container
runtime και τον ρόλο του πήρε, το runC, προκειμένου να μπορέσουν τα δοχεία του
Docker να δουλεύουν ευκολότερα σε διαφορετικές πλατφόρμες όπως το Kubernetes
\cite{containerdRunc}. Επιπροσθέτως, η απόφαση αυτή κατέστησε το Docker πιο
διαχειρίσιμο διότι πλέον αποτελούνταν από πολλά μικρότερα εργαλεία, όπου το
καθένα από αυτά είχε συγκεκριμένους ρόλους. Αναλυτικότερα, το containerd πλέον
είναι υπεύθυνο για την απόκτηση εικόνων δοχείων και την διαχείρισή τους, προτού
τις μεταβιβάσει στο runC, το οποίο είναι το εργαλείο που θα αλληλεπιδράσει με
τον πυρήνα του Linux προκειμένου να χρησιμοποιήσει χαρακτηριστικά όπως, οι
ομάδες ελέγχου (control groups), για να δημιουργήσει δοχεία.

\subsection{Ασφάλεια στο Docker} \label{dockerSecurityMore}

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

Σχετικά με τις εικόνες δοχείων που αναφέρθηκαν στο
\ref{virtualizationTechnologiesIntroduction} και το
\ref{containersAndContainerImages}, τα κομμάτια δηλαδή από τα οποία μια
εφαρμογή σε μορφή δοχείου αποτελείται και αντιστοιχούν σε καλούπια μέσω των
οποίων παράγονται τα δοχεία της εφαρμογής, η ασφάλεια δεν είναι πάντα
εγγυημένη. Αυτό είναι κάτι που συμβαίνει διότι ο καθένας έχει την δυνατότητα να
ανεβάσει μια εικόνα δοχείου προς χρήση από τρίτους. Σε περίπτωση που δεν
εξετασθεί το περιεχόμενό της μπορεί είτε να περιέχει κακόβουλο λογισμικό, είτε
να μην ακολουθούνται ορθές πρακτικές ασφαλείας με αποτέλεσμα να μένει το
σύστημα που την χρησιμοποιεί ευάλωτο σε επιθέσεις. Συνεπώς, πρέπει να ληφθούν
μέτρα προστασίας όπως η χρήση εικόνων προερχόμενες μόνο από εγκεκριμένες πηγές,
δηλαδή να υπάρχει εμπιστοσύνη ανάμεσα στον προμηθευτή μιας εικόνας δοχείου και
τον τελικό χρήστη. Επιπροσθέτως, πριν την χρήση μιας εικόνας δοχείου, πρέπει
αυτή να εξετάζεται με εργαλεία ανίχνευσης τρωτοτήτων, καθώς και να έχει
πραγματοποιηθεί επαρκώς σκλήρυνση του Docker ώστε να μειωθούν οι επιπτώσεις
κατά την χρήση της εαν περιέχει κακόβουλο λογισμικό.

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

\subsubsection{Μετριασμός επιθέσεων στο Docker με χρήση χώρων ονομάτων} \label{dockerAttackVectorMitigation}

Με βάση το μοντέλο που περιγράφει το \cite{reshetova2014security}, όπως
αναφέρεται στο \cite{bui2015analysis}, έχουμε ένα μηχάνημα στο οποίο
εκτελούνται διάφορα δοχεία, από τα οποία ένα υποσύνολο έχει τεθεί υπό τον
έλεγχο ενός κακόβουλου χρήστη. Για να προστατευτούμε από επιθέσεις, όπως άρνηση
υπηρεσίας και κλιμάκωση δικαιωμάτων, πρέπει να πραγματοποιηθεί απομόνωση των
διεργασιών, των αρχείων της συσκευής, του IPC, του δικτύου και των πόρων.

Αυτά επιτυγχάνονται κατά σειρά με τη χρήση:

\begin{itemize}

    \item \textbf{Χώρων ονομάτων (namespaces)} όπου οριοθετείται η ορατότητα
        των διεργασιών ανάμεσα στα δοχεία και το σύστημα, όπως επίσης και τα
        δικαιώματά τους.

    \item \textbf{Mount namespaces}, με τα οποία οι διεργασίες κάθε δοχείου
        βλέπουν με διαφορετικό τρόπο τη διάταξη των αρχείων του συστήματος.
        Όλες οι δράσεις mount, που γίνονται στο εκάστοτε δοχείο, περιορίζονται
        σε αυτό. Επίσης, οριοθετούνται τα δικαιώματα των αρχείων του πυρήνα σε
        μονάχα ανάγνωσης και αποτρέπονται περαιτέρω remountings.

    \item \textbf{Device Whitelist Controller}, ενός χαρακτηριστικού
        \cite{deviceWhitelistController} των cgroups για περιορισμό
        συσκευών, με τη βοήθεια του οποίου περιορίζεται το σύνολο τον συσκευών
        στις οποίες έχει πρόσβαση ένα δοχείο και το αποτρέπει από το να
        δημιουργήσει καινούριες αναπαραστάσεις συσκευών. Επιπροσθέτως, επειδή
        τα mount γίνονται με τη χρήση της παραμέτρου
        nodev\footnote{\textgreek{Μια παράμετρος της εντολής mount κατά την
        οποία αποτρέπεται η δημιουργία και η πρόσβαση αναπαραστάσεων συσκευών
        που βρίσκονται στον φάκελο /dev.}}, στην περίπτωση που μια αναπαράσταση
        συσκευής είχε δημιουργηθεί σε προηγούμενο χρόνο μέσα στην εικόνα δοχείου που
        χρησιμοποιήθηκε για να κατασκευαστεί το δοχείο, οι διεργασίες του δοχείου αυτού
        δε δύνανται να τη χρησιμοποιήσουν για να επικοινωνήσουν με τον πυρήνα.
        Επιπλέον, επειδή η προεπιλεγμένη συνθήκη είναι να μη δίνονται εκτεταμένα
        προνόμια σε ένα δοχείο, δεν υπάρχει πρόσβαση σε καμία συσκευή παρά μόνο εάν
        γίνει εκτέλεση δοχείου ως χρήστης με ανώτατα δικαιώματα, όπου τότε υπάρχει
        πρόσβαση σε όλες (τις συσκευές).

    \item \textbf{IPC namespaces} για περιορισμό IPC, δηλαδή της επικοινωνίας
        των διεργασιών μεταξύ τους. Τα IPC namespaces καθιστούν δυνατή τη
        δημιουργία ξεχωριστών συνόλων των διεργασιών που επικοινωνούν μεταξύ
        τους, αλλά όχι με άλλες διεργασίες πέραν του υποσυνόλου.

    \item \textbf{Network namespaces}. Μία από τις σημαντικότερες απομονώσεις
        είναι αυτή του δικτύου. Χωρίς δικτυακή απομόνωση υπάρχει κίνδυνος
        επιθέσεων, όπως ενδιάμεσου (Man in the middle), ARP, DNS πλαστογράφησης
        (spoofing) και άλλες. Για να απομονωθεί η κίνηση δικτύου που λαμβάνει
        μέρος σε ένα δοχείο από αυτήν των υπολοίπων και του συστήματος πρέπει
        να γίνει χρήση των network namespaces. Κάθε δοχείο θα έχει δικές του
        διευθύνσεις IP, συσκευές και ό,τι χρειάζεται, προκειμένου να γίνεται
        αλληλεπίδραση μεταξύ των δοχείων μέσω της διεπαφής δικτύου του καθενός
        σαν να είναι εξωτερικές οντότητες.

    \item \textbf{Ομάδες ελέγχου (cgroups)}. Επιβάλλεται η οριοθέτηση των
        υπολογιστικών πόρων προκειμένου να αποφευχθεί μια επίθεση τύπου άρνησης
        υπηρεσίας, όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί να
        καταναλώσει όλους τους πόρους του συστήματος. Με τη βοήθεια των ομάδων
        ελέγχου, επιτυγχάνεται ο έλεγχος του (μέγιστου) ποσοστού πόρων όπως
        CPU, μνήμης και χωρητικότητας, που μπορεί να έχει κάθε δοχείο στη
        διάθεση του.

\end{itemize}

Αυτές οι δυνατότητες υποστηρίζονται από το Docker και μπορεί κανείς να τις
εκμεταλλευτεί για να προστατεύσει το περιβάλλον του από επιθέσεις. Επιπλέον,
υπάρχει και η δυνατότητα υποστήριξης Kernel Security Modules, όπως τα SELinux
\cite{selinux} και AppArmor \footfullcite{apparmor} αλλά και του Seccomp
\cite{seccomp} (στην περίπτωση χρήσης LXC), καθώς επίσης και συμβατότητα με
Linux capabilities (ικανότητες), που θα μπορούσαν να εισάγουν ένα ακόμα επίπεδο
ασφαλείας, αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα των διεργασιών
των δοχείων σε μονάχα όσα χρειάζονται. Το Docker παρέχει αρκετά υπάρχοντα μέσα
άμυνας προκειμένου να προστατευτεί από επιθέσεις ακόμα και χωρίς επιπρόσθετες
ρυθμίσεις. Παρ' όλα αυτά, οι αρχικές ρυθμίσεις ασφαλείας του είναι πιο
ελαστικές απ' όσο χρειάζεται προκειμένου να συνεχίζει να λειτουργεί κανονικά
για όλους τους χρήστες, αφήνοντας έτσι τους διαχειριστές ασφαλείας υπεύθυνους
να χρησιμοποιήσουν όσες δυνατότητες είναι απαραίτητες προκειμένου να
ανταπεξέλθουν σε κάθε επίθεση ανάλογα με το περιβάλλον και τις ανάγκες τους.

\subsubsection{Συχνά είδη επιθέσεων σε δοχεία και μέθοδοι πρόληψής τους} \label{commonAttacksAndPrevention}

Μερικά είδη επιθέσεων σε δοχεία με τους τρόπους αντιμετώπισής τους, όπως
αναφέρονται στο \cite{yasrab2018mitigating}, είναι τα εξής:

\begin{itemize}

    \item \textbf{Εκμεταλλεύσεις πυρήνα (Kernel Exploits)}:

        Ο πυρήνας είναι υπεύθυνος για τη διαχείριση των λειτουργιών και
        διεργασιών των δοχείων. Λόγω του διαμοιρασμού του πυρήνα του συστήματος
        με κάθε δοχείο το οποίο εκτελείται σε αυτό, εάν οποιοδήποτε από αυτά
        τεθεί υπό τον έλεγχο ενός κακόβουλου χρήστη, αυτός μπορεί δυνητικά να
        πάρει τον έλεγχο του συστήματος και όλων των δοχείων αυτού. Ο τρόπος
        αντιμετώπισης που προτείνεται είναι η χρήση SELinux ή AppArmor κατά την
        εκτέλεση δοχείων σε συνδυασμό με εκμετάλλευση των user namespaces.
        Επιπλέον, συνίσταται να μην εκτελούνται εφαρμογές με δικαιώματα
        διαχειριστικού λογαριασμού. Μερικά ακόμα μέτρα προστασίας που μπορεί να
        παρθούν αλλά πιθανώς να μην είναι εφικτά γιατί ενδεχομένως να πηγαίνουν
        ενάντια στις λειτουργίες του εκάστοτε δοχείου, είναι να τεθεί το
        σύστημα του σε επίπεδο πρόσβασης που επιτρέπει μόνο την ανάγνωση των
        αρχείων, να απενεργοποιηθεί η επικοινωνία μεταξύ δοχείων και να
        αποφευχθεί η εγκατάσταση περιττών προγραμμάτων σε αυτά.

\clearpage

    \item \textbf{Άρνηση υπηρεσίας}:

        Μια από τις πιο συνηθισμένες επιθέσεις σε πόρους διαθέσιμους μέσω
        δικτύου είναι η άρνηση υπηρεσίας. Κατά τη διάρκεια μιας τέτοιας
        επίθεσης, μια διεργασία ή ένα σύνολο διεργασιών επιχειρεί να
        καταναλώσει όλους τους πόρους του συστήματος προκειμένου να μην μπορεί
        να εξυπηρετήσει άλλους χρήστες. Αυτό μπορεί να συμβεί εάν ένα δοχείο
        βρεθεί υπό τον έλεγχο ενός επιτιθέμενου και επιχειρήσει να διεκδικήσει
        πόρους που κανονικά δε χρειάζεται. Για να ανταπεξέλθει ένα σύστημα σε
        μια επίθεση άρνησης υπηρεσίας, πρέπει να γίνει χρήση των δυνατοτήτων
        που αναφέραμε στο \ref{dockerAttackVectorMitigation} με σκοπό τον
        αυστηρότερο έλεγχο διαμοιρασμού των πόρων του συστήματος. Με τον
        καθορισμό μέγιστων διαθέσιμων πόρων για κάθε δοχείο εξ αρχής, δεν
        υπάρχει κίνδυνος να προσπαθήσει κάποιο δοχείο να διεκδικήσει
        περισσότερους από αυτούς που μπορούν να του ανατεθούν.

    \item \textbf{Αποδράσεις Δοχείων (Container Breakouts)}:

        Σε τέτοιου είδους επιθέσεις, ένας επιτιθέμενος προσπαθεί αφού απέκτησε
        πρόσβαση σε ένα δοχείο, να καταφέρει μέσω αυτού να έχει πρόσβαση στα
        αρχεία του κύριου συστήματος. Αυτό μπορεί να συμβεί με τη χρήση μιας
        συνάρτησης που απαιτεί δικαιώματα διαχειριστικού λογαριασμού μέσα από
        το δοχείο προκειμένου να κάνει κλήση μιας ικανότητας (capability) στην
        οποία είχε πρόσβαση εξ αρχής. Σύμφωνα με το Docker, η μόνη έκδοσή του
        που μπορούσε να επηρεαστεί από αυτή την ευπάθεια ήταν η 0.11 και στην
        επόμενη διορθώθηκε. Για την πρόληψη μελλοντικών μεθόδων διεκπεραίωσης
        τέτοιου είδους επίθεσης, συνίσταται να τίθενται τα δοχεία και οι
        αποθηκευτικοί τους χώροι σε κατάσταση μονάχα ανάγνωσης, καθώς και να
        αποφεύγεται η χρήση της παραμέτρου \textquote{privileged}.

    \item \textbf{Δηλητηριασμένες εικόνες δοχείων}:

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

\clearpage

    \item \textbf{Απόκτηση μυστικών κωδικών/κλειδιών}:

        Η απόκτηση επιχειρησιακών ή προσωπικών μυστικών ελλοχεύει πολλούς
        κινδύνους για μια επιχείρηση. Σε περίπτωση που κάτι τέτοιο συμβεί, ένας
        επιτιθέμενος μπορεί να έχει πρόσβαση σε βάσεις δεδομένων ή άλλα
        κομμάτια του συστήματος απειλώντας έτσι την ακεραιότητα, την
        εμπιστευτικότητα και διαθεσιμότητα των δεδομένων. Προκειμένου να
        αποφευχθεί η εισβολή σε κάποιο δοχείο που θα προκαλούσε την απόκτηση
        τέτοιων μυστικών, καθίσταται επιτακτική η χρήση δοχείων σε κατάσταση
        ανάγνωσης και όχι εγγραφής αλλά και η αποφυγή χρήσης μεταβλητών για την
        αποθήκευση κωδικών. Χρήσιμη επίσης θα ήταν και η εσκεμμένη παράλειψη
        της παραμέτρου \textquote{privileged}.

    \item \textbf{Ενδιάμεσου (Man-in-the-Middle - MitM)}:

        Σε μια τέτοια επίθεση ένας κακόβουλος χρήστης προσπαθεί να μπει ανάμεσα
        στην επικοινωνία δύο οντοτήτων με σκοπό να αλλοιώσει, να υποκλέψει ή να
        παρακολουθεί πληροφορίες. Το καλύτερο αντίμετρο είναι η απομόνωση
        δικτύου. Πρέπει να γίνει ρύθμιση των δοχείων με τέτοιο τρόπο ώστε αυτά
        να μην έχουν πρόσβαση στη δικτυακή επικοινωνία του κύριου μηχανήματος ή
        άλλων δοχείων. Αυτά επιτυγχάνονται με χρήση network namespaces, καθώς
        και με την ορθότερη ρύθμιση των API που χρησιμοποιεί το Docker για την
        επικοινωνία μέσω δικτύου.

    \item \textbf{Πλαστογράφηση ARP (ARP spoofing)}:

        Σε μια επίθεση πλαστογράφησης Address Resource Protocol (ARP), ο
        επιτιθέμενος επιχειρεί να στείλει ψεύτικα ARP μηνύματα σε ένα δίκτυο
        τοπικής περιοχής (Local Area Network - LAN). Είναι πιθανό να
        προσποιηθεί πως η συσκευή του είναι μια από τις συσκευές της
        επιχείρησης, αλλάζοντας τη MAC διεύθυνσή του στην IP μιας συσκευής που
        το σύστημα αναγνωρίζει. Επομένως, το σύστημα της επιχείρησης, θα
        συμπεριφέρεται στην συσκευή του επιτιθέμενου με τον ίδιο τρόπο που θα
        συμπεριφερόταν στην αυθεντική συσκευή. Δηλαδή, στέλνοντας σε αυτόν όλα
        τα πακέτα και τα δεδομένα που προορίζονταν για εκείνη. Το Docker
        χρησιμοποιεί το ARP για να κάνει την αντιστοίχιση IPv4 σε MAC
        διευθύνσεις, οι οποίες χρησιμοποιούνται από την εικονική γέφυρα δικτύου
        για να διανέμουν σωστά τα πλαίσια (frames) Ethernet αφού δεν υπάρχει
        φίλτρο για τα πακέτα ARP και επομένως κανένας μηχανισμός άμυνας. Γι'
        αυτό τον λόγο ένα δοχείο μπορεί να προσποιηθεί ότι είναι ένα άλλο ή
        ακόμα και το κύριο μηχάνημα. Στην περίπτωση παραβίασης ενός δοχείου,
        υπάρχει κίνδυνος ο επιτιθέμενος να υποκλέψει μυστικά της επιχείρησης ή
        των τελικών χρηστών της υπηρεσίας που η επιχείρηση προσφέρει. Ένας από
        τους τρόπους που βοηθάει στην αποφυγή τέτοιας επίθεσης είναι η εκτέλεση
        δοχείων δίχως το NET\_RAW capability, αφού έτσι τα προγράμματα μέσα στο
        δοχείο δε θα μπορούν να δημιουργήσουν PF\_PACKET sockets και θα ήταν
        αδύνατη η διεκπεραίωση της επίθεσης. Βέβαια, αυτή η μέθοδος έχει
        μειονεκτήματα αφού μπορεί αυτή η ικανότητα να ήταν άκρως απαραίτητη για
        την ορθή λειτουργία της υπηρεσίας. Επομένως, μια εναλλακτική μέθοδος
        προστασίας είναι η χρήση \textquote{ebtables} για φιλτράρισμα πλαισίων
        Ethernet ούτως ώστε ARP πακέτα με λάθος πρωτόκολλο αποστολέα ή
        διεύθυνση MAC να ανιχνεύονται εγκαίρως και να απορρίπτονται.

\end{itemize}
