Fuck it, YOLO!
This commit is contained in:
45
Abbreviations/abbreviations.tex
Normal file
45
Abbreviations/abbreviations.tex
Normal file
@@ -0,0 +1,45 @@
|
||||
\setstretch{1.5} % Set the line spacing to 1.5, this makes the following tables easier to read
|
||||
\clearpage % Start a new page
|
||||
\lhead{\emph{Συντομογραφίες}} % Set the left side page header to "Abbreviations"
|
||||
\listofsymbols{ll} % Include a list of Abbreviations (a table of two columns)
|
||||
{
|
||||
\textbf{IaaS} & \textbf{I}nfrastructure \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{PaaS} & \textbf{P}latform \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{SaaS} & \textbf{S}oftware \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{AWS} & \textbf{A}mazon \textbf{W}eb \textbf{S}ervices \\
|
||||
\textbf{EC2} & \textbf{E}lastic \textbf{C}ompute \textbf{C}loud \\
|
||||
\textbf{API} & \textbf{A}pplication \textbf{P}rogramming \textbf{I}nterface \\
|
||||
\textbf{SDK} & \textbf{S}oftware \textbf{D}evelopment \textbf{K}it \\
|
||||
\textbf{OS} & \textbf{O}perating \textbf{S}ystem \\
|
||||
\textbf{BIOS} & \textbf{B}asic \textbf{I}nput/\textbf{O}utput \textbf{S}ystem \\
|
||||
\textbf{UEFI} & \textbf{U}nified \textbf{E}xtensible \textbf{F}irmware \textbf{I}nterface \\
|
||||
\textbf{MAC} & \textbf{M}andatory \textbf{A}ccess \textbf{C}ontrol \\
|
||||
\textbf{XSS} & \textbf{C}ross \textbf{S}ite \textbf{S}cripting \\
|
||||
\textbf{cgroups} & \textbf{c}ontrol groups \\
|
||||
\textbf{CI/CD} & \textbf{C}ontinuous \textbf{I}ntegration / \textbf{C}ontinuous \textbf{D}elivery \\
|
||||
\textbf{DevOps} & \textbf{Dev}elopment \textbf{Op}eration\textbf{s} \\
|
||||
\textbf{LXC} & \textbf{L}inu\textbf{x} \textbf{C}ontainers \\
|
||||
\textbf{OCI} & \textbf{O}pen \textbf{C}ontainer \textbf{I}nitiative \\
|
||||
\textbf{TPM} & \textbf{T}rusted \textbf{P}latform \textbf{M}odule \\
|
||||
\textbf{VM} & \textbf{V}irtual \textbf{M}achine \\
|
||||
\textbf{VBS} & \textbf{V}irtualization-\textbf{B}ased \textbf{S}ecurity \\
|
||||
\textbf{KVM} & \textbf{K}ernel-based \textbf{V}irtual \textbf{M}achine \\
|
||||
\textbf{VMM} & \textbf{V}irtual \textbf{M}achine \textbf{M}onitor \\
|
||||
\textbf{NFV} & \textbf{N}etwork \textbf{F}unction \textbf{V}irtualization \\
|
||||
\textbf{IPC} & \textbf{I}nter \textbf{P}rocess \textbf{C}ommunication \\
|
||||
\textbf{ARP} & \textbf{A}ddress \textbf{R}esolution \textbf{P}rotocol \\
|
||||
\textbf{DNS} & \textbf{D}omain \textbf{N}ame \textbf{S}ystem \\
|
||||
\textbf{MitM} & \textbf{M}an-\textbf{i}n-\textbf{t}he-\textbf{M}iddle \\
|
||||
\textbf{CPU} & \textbf{C}entral \textbf{P}rocessing \textbf{U}nit \\
|
||||
\textbf{SELinux} & \textbf{S}ecurity-\textbf{E}nhanced \textbf{L}inux \\
|
||||
\textbf{SecComp} & \textbf{Sec}ure \textbf{Comp}uting \\
|
||||
\textbf{AppArmor} & \textbf{App}lication Armor \\
|
||||
\textbf{IP} & \textbf{I}nternet \textbf{P}rotocol \\
|
||||
\textbf{IPv4} & \textbf{I}nternet \textbf{P}rotocol \textbf{v}ersion 4 \\
|
||||
\textbf{LAN} & \textbf{L}ocal \textbf{A}rea \textbf{N}etwork \\
|
||||
\textbf{RAM} & \textbf{R}andom \textbf{A}ccess \textbf{M}emory \\
|
||||
\textbf{ΛΣ} & \textbf{Λ}ειτουργικό \textbf{Σ}ύστημα \\
|
||||
\textbf{ΤΠ} & \textbf{Τ}εχνολογίες \textbf{Π}ληροφορικής \\
|
||||
}
|
||||
|
||||
\lhead{}
|
||||
54
Abstract/abstract.tex
Normal file
54
Abstract/abstract.tex
Normal file
@@ -0,0 +1,54 @@
|
||||
\addtotoc{Σύνοψη} % Add the "Abstract" page entry to the Contents
|
||||
\abstract{
|
||||
\addtocontents{toc}{\vspace{1em}} % Add a gap in the Contents, for aesthetics
|
||||
% skip indentation just for this paragraph
|
||||
|
||||
\hyphenation{αυτές νέφος}
|
||||
|
||||
\noindent Τη σημερινή εποχή, όλο και περισσότερος κόσμος βασίζεται πλέον σε
|
||||
υπηρεσίες τύπου IaaS έναντι των παραδοσιακών επιτόπιων υποδομών για την παροχή
|
||||
λειτουργικής υποστήριξης σε εφαρμογές, υπηρεσίες και επιχειρησιακές
|
||||
διαδικασίες. Αυτό συμβαίνει διότι κατ' αυτό τον τρόπο μειώνονται τα έξοδα ενός
|
||||
οργανισμού ή μιας επιχείρησης εφόσον δεν υπάρχει ανάγκη δαπάνης/επένδυσης για
|
||||
την αγορά εξοπλισμού και το λειτουργικό κόστος χρήσης υπηρεσιών IaaS βασίζεται
|
||||
σε ευέλικτα μοντέλα χρέωσης με βάση την χρήση (των πόρων υποδομής που
|
||||
προσφέρονται). Επιπλέον, είναι δυνατή η κλιμάκωση της προσφερόμενης
|
||||
απομακρυσμένης υποδομής ανάλογα με τις ανάγκες του οργανισμού και του τρέχοντος
|
||||
φόρτου εργασίας των υπηρεσιών και εφαρμογών προς υποστήριξη. Με αυτόν τον
|
||||
τρόπο, μεταβιβάζεται η ευθύνη της διάθεσης και συντήρησης του εξοπλισμού σε
|
||||
τρίτους ενώ ταυτόχρονα εισάγεται ένα καινούριο μοντέλο εμπιστοσύνης ανάμεσα
|
||||
στον χρήστη/οργανισμό και τον πάροχο νέφους. Η αύξηση ενδιαφέροντος από τις
|
||||
επιχειρήσεις προς τις τεχνολογίες εικονικοποίησης οι οποίες αποτελούν τα
|
||||
θεμέλια των υπηρεσιών IaaS, αλλά και η ραγδαία άνοδος της δημοτικότητας
|
||||
τεχνολογιών δοχείων όπως είναι το Docker άρχισε με την σειρά της να ενισχύει
|
||||
την υιοθέτηση της αρχιτεκτονικής μικρο-υπηρεσιών για την ανάπτυξη εφαρμογών.
|
||||
Μιας αρχιτεκτονικής που βασίζεται τόσο στις τεχνολογίες εικονικοποίησης για την
|
||||
στέγαση των εφαρμογών σε υποδομές νέφους όσο και στις τεχνολογίες δοχείων για
|
||||
την διαμέριση των λειτουργιών τους, προσφέροντας ένα κατάλληλο επίπεδο απόδοσης
|
||||
και κλιμακωσιμότητας \footfullcite{awsMicroservices}. Ωστόσο, παραμένουν άμεσα
|
||||
ευεπηρέαστες σε ζητήματα ασφάλειας που μπορεί να αφορούν το ίδιο το νέφος ή/και
|
||||
τις τεχνολογίες στις οποίες στηρίζεται.
|
||||
|
||||
\clearpage
|
||||
|
||||
Στην παρούσα εργασία θα αναλύσουμε πρώτα τα ζητήματα ασφάλειας που αφορούν το
|
||||
νέφος και ειδικότερα αυτά που αφορούν τις τεχνολογίες εικονικοποίησης και
|
||||
δοχείων. Έπειτα, θα αναλύσουμε πως μπορεί να γίνει χρήση αυτών των 2
|
||||
τεχνολογιών με περισσότερη ασφάλεια. Όμως ο σκοπός της εργασίας προχωρά πέρα
|
||||
από αυτό και μεταβαίνει σε ένα πρακτικό επίπεδο, προτείνοντας τη λύση ενός
|
||||
εργαλείου που μπορεί να υλοποιεί με αυτό τον τρόπο την προτεινόμενη, ασφαλή
|
||||
χρήση των τεχνολογιών αυτών. Ειδικότερα, το εργαλείο αυτό όχι μόνο μπορεί να
|
||||
δημιουργεί εικονικές μηχανές κατά μήκος πολλών παρόχων νέφους αλλά και να τις
|
||||
σκληραίνει με έναν αυτοματοποιημένο τρόπο. Επιπροσθέτως, είναι ικανό να
|
||||
εγκαθιστά σε αυτές τις εικονικές μηχανές τη μηχανή δοχείων Docker, την οποία
|
||||
επίσης μπορεί να σκληραίνει. Ο βασικός στόχος της εργασίας είναι να διευκολύνει
|
||||
έναν οργανισμό στην εγκατάσταση και διαμόρφωση με αυτοματοποιημένο τρόπο ενός
|
||||
ασφαλούς, κατανεμημένου περιβάλλοντος (φιλοξενίας και λειτουργίας) για την
|
||||
εγκατάσταση και λειτουργία μιας εφαρμογής μικρο-υπηρεσιών. Η αυτοματοποίηση
|
||||
αυτή έγκειται στη σωστή διαμόρφωση του εργαλείου, η οποία δεν προϋποθέτει
|
||||
κάποια ειδική γνώση πάνω σε τεχνικά ζητήματα αλλά ούτε και στον τομέα της
|
||||
ασφάλειας υποδομών και των λειτουργικών συστημάτων.
|
||||
|
||||
}
|
||||
|
||||
\clearpage % Abstract ended, start a new page
|
||||
877
Bibliography.bib
877
Bibliography.bib
@@ -16,17 +16,17 @@
|
||||
}
|
||||
|
||||
@inproceedings{manu2016study,
|
||||
author={Manu, A.R. and Patel, Jitendra Kumar and Akhtar, Shakil and Agrawal, V.K. and Subramanya Murthy, K.N. Bala},
|
||||
booktitle={2016 International Conference on Circuit, Power and Computing Technologies (ICCPCT)},
|
||||
title={A study, analysis and deep dive on cloud PAAS security in terms of Docker container security},
|
||||
year={2016},
|
||||
volume={},
|
||||
number={},
|
||||
pages={1-13},
|
||||
doi={10.1109/ICCPCT.2016.7530284}
|
||||
author = {Manu, A.R. and Patel, Jitendra Kumar and Akhtar, Shakil and Agrawal, V.K. and Subramanya Murthy, K.N. Bala},
|
||||
booktitle = {2016 International Conference on Circuit, Power and Computing Technologies (ICCPCT)},
|
||||
title = {A study, analysis and deep dive on cloud PAAS security in terms of Docker container security},
|
||||
year = {2016},
|
||||
volume = {},
|
||||
number = {},
|
||||
pages = {1-13},
|
||||
doi = {10.1109/ICCPCT.2016.7530284}
|
||||
}
|
||||
|
||||
@misc{bui2015analysis,
|
||||
@online{bui2015analysis,
|
||||
doi = {10.48550/ARXIV.1501.02967},
|
||||
url = {https://arxiv.org/abs/1501.02967},
|
||||
author = {Bui, Thanh},
|
||||
@@ -38,64 +38,64 @@
|
||||
}
|
||||
|
||||
@inproceedings{wenhao2020vulnerability,
|
||||
author={Wenhao, Jiang and Zheng, Li},
|
||||
booktitle={2020 IEEE 3rd International Conference on Information Systems and Computer Aided Education (ICISCAE)},
|
||||
title={Vulnerability Analysis and Security Research of Docker Container},
|
||||
year={2020},
|
||||
volume={},
|
||||
number={},
|
||||
pages={354-357},
|
||||
doi={10.1109/ICISCAE51034.2020.9236837}
|
||||
author = {Wenhao, Jiang and Zheng, Li},
|
||||
booktitle = {2020 IEEE 3rd International Conference on Information Systems and Computer Aided Education (ICISCAE)},
|
||||
title = {Vulnerability Analysis and Security Research of Docker Container},
|
||||
year = {2020},
|
||||
volume = {},
|
||||
number = {},
|
||||
pages = {354-357},
|
||||
doi = {10.1109/ICISCAE51034.2020.9236837}
|
||||
}
|
||||
|
||||
@article{combe2016docker,
|
||||
author={Combe, Theo and Martin, Antony and Di Pietro, Roberto},
|
||||
journal={IEEE Cloud Computing},
|
||||
title={To Docker or Not to Docker: A Security Perspective},
|
||||
year={2016},
|
||||
volume={3},
|
||||
number={5},
|
||||
pages={54-62},
|
||||
keywords={},
|
||||
doi={10.1109/MCC.2016.100},
|
||||
ISSN={2325-6095},
|
||||
month={Sep.}
|
||||
author = {Combe, Theo and Martin, Antony and Di Pietro, Roberto},
|
||||
journal = {IEEE Cloud Computing},
|
||||
title = {To Docker or Not to Docker: A Security Perspective},
|
||||
year = {2016},
|
||||
volume = {3},
|
||||
number = {5},
|
||||
pages = {54-62},
|
||||
keywords = {},
|
||||
doi = {10.1109/MCC.2016.100},
|
||||
ISSN = {2325-6095},
|
||||
month = {Sep.}
|
||||
}
|
||||
|
||||
@inproceedings{loukidis2018docker,
|
||||
author={Loukidis-Andreou, Fotis and Giannakopoulos, Ioannis and Doka, Katerina and Koziris, Nectarios},
|
||||
booktitle={2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS)},
|
||||
title={Docker-Sec: A Fully Automated Container Security Enhancement Mechanism},
|
||||
year={2018},
|
||||
volume={},
|
||||
number={},
|
||||
pages={1561-1564},
|
||||
doi={10.1109/ICDCS.2018.00169}
|
||||
author = {Loukidis-Andreou, Fotis and Giannakopoulos, Ioannis and Doka, Katerina and Koziris, Nectarios},
|
||||
booktitle = {2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS)},
|
||||
title = {Docker-Sec: A Fully Automated Container Security Enhancement Mechanism},
|
||||
year = {2018},
|
||||
volume = {},
|
||||
number = {},
|
||||
pages = {1561-1564},
|
||||
doi = {10.1109/ICDCS.2018.00169}
|
||||
}
|
||||
|
||||
@inproceedings{mp2016enhancing,
|
||||
author={Amith Raj MP and Kumar, Ashok and Pai, Sahithya J and Gopal, Ashika},
|
||||
booktitle={2016 2nd International Conference on Applied and Theoretical Computing and Communication Technology (iCATccT)},
|
||||
title={Enhancing security of Docker using Linux hardening techniques},
|
||||
year={2016},
|
||||
volume={},
|
||||
number={},
|
||||
pages={94-99},
|
||||
doi={10.1109/ICATCCT.2016.7911971}
|
||||
author = {Amith Raj MP and Kumar, Ashok and Pai, Sahithya J and Gopal, Ashika},
|
||||
booktitle = {2016 2nd International Conference on Applied and Theoretical Computing and Communication Technology (iCATccT)},
|
||||
title = {Enhancing security of Docker using Linux hardening techniques},
|
||||
year = {2016},
|
||||
volume = {},
|
||||
number = {},
|
||||
pages = {94-99},
|
||||
doi = {10.1109/ICATCCT.2016.7911971}
|
||||
}
|
||||
|
||||
@article{jogi2017establishing,
|
||||
title={Establishing, Implementing and Auditing Linux Operating System Hardening Standard for Security Compliance},
|
||||
author={Jogi, Martin},
|
||||
journal={University of Tartu, Tartu},
|
||||
year={2017}
|
||||
title = {Establishing, Implementing and Auditing Linux Operating System Hardening Standard for Security Compliance},
|
||||
author = {Jogi, Martin},
|
||||
journal = {University of Tartu, Tartu},
|
||||
year = {2017}
|
||||
}
|
||||
|
||||
@article{kaur2014hardening,
|
||||
title={Hardening OS Identity by Customised Masking Techniques},
|
||||
author={Kaur, Ratinder and Singh, Maninder},
|
||||
journal={Thapar University, Punjab, India},
|
||||
year={2014}
|
||||
title = {Hardening OS Identity by Customised Masking Techniques},
|
||||
author = {Kaur, Ratinder and Singh, Maninder},
|
||||
journal = {Thapar University, Punjab, India},
|
||||
year = {2014}
|
||||
}
|
||||
|
||||
@article{zhu2021lic,
|
||||
@@ -112,204 +112,711 @@
|
||||
}
|
||||
|
||||
@misc{John2020OS,
|
||||
title={OS Hardening - Making systems more secure},
|
||||
author={John Ostrowski},
|
||||
year={2020}
|
||||
title = {OS Hardening - Making systems more secure},
|
||||
author = {John Ostrowski},
|
||||
year = {2020}
|
||||
}
|
||||
|
||||
@misc{SIDDARTH201910simple,
|
||||
title={10 Simple Steps to Harden Your Docker Containers},
|
||||
author={SIDDARTH SENTHILKUMAR},
|
||||
howpublished="\url{https://sidsbits.com/10-Simple-Steps-to-Harden-Docker-Containers/}",
|
||||
year={2019}
|
||||
@online{containerHistory,
|
||||
title = {The evolution of containers: Docker, Kubernetes and the future},
|
||||
author = {Emily Mell},
|
||||
year = {2023},
|
||||
url = {https://www.techtarget.com/searchitoperations/feature/Dive-into-the-decades-long-history-of-container-technology}
|
||||
}
|
||||
|
||||
@misc{Yathi2017Hardening,
|
||||
title={Hardening Docker containers, images, and host - security toolkit},
|
||||
author={Yathi Naik},
|
||||
howpublished="\url{https://cloud.redhat.com/blog/hardening-docker-containers-images-and-host-security-toolkit}",
|
||||
year={2017}
|
||||
@online{chrootCommand,
|
||||
title = {The chroot command in Linux – Beginners Introduction},
|
||||
author = {Deeptendu Santra},
|
||||
year = {2021},
|
||||
url = {https://www.linuxfordevices.com/tutorials/linux/chroot-command-in-linux}
|
||||
}
|
||||
|
||||
@misc{StackRox2019Docker,
|
||||
title={Docker Container Security 101: Risks and 33 Best Practices},
|
||||
author={StackRox},
|
||||
howpublished="\url{https://www.stackrox.io/blog/docker-security-101/}",
|
||||
year={2019}
|
||||
@online{SIDDARTH201910simple,
|
||||
title = {10 Simple Steps to Harden Your Docker Containers},
|
||||
author = {SIDDARTH SENTHILKUMAR},
|
||||
url = {https://sidsbits.com/10-Simple-Steps-to-Harden-Docker-Containers/},
|
||||
year = {2019}
|
||||
}
|
||||
|
||||
@misc{Marcin2019Hardening,
|
||||
title={Hardening Docker Quick Tips},
|
||||
author={Marcin Teodorczyk},
|
||||
howpublished="\url{https://medium.com/intive-developers/hardening-docker-quick-tips-54ca9c283964}",
|
||||
year={2019}
|
||||
@online{LXC,
|
||||
title = {What's LXC?},
|
||||
author = {Linux Containers},
|
||||
url = {https://linuxcontainers.org/lxc/introduction/},
|
||||
}
|
||||
|
||||
@misc{deviceWhitelistController,
|
||||
title={Device Whitelist Controller},
|
||||
author={The Linux kernel user’s and administrator’s guide},
|
||||
howpublished="\url{https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html}"
|
||||
@online{LXCvsDocker,
|
||||
title = {LXC vs Docker: Which Container Platform Is Right for You?},
|
||||
author = {Eric Kahuha},
|
||||
year = {2023},
|
||||
url = {https://earthly.dev/blog/lxc-vs-docker/}
|
||||
}
|
||||
|
||||
@misc{dockerInherentSecurity,
|
||||
title={The Inherent Security Benefits of Docker Containers},
|
||||
author={Christopher Tozzi},
|
||||
howpublished="\url{https://cloudnativenow.com/features/security-benefits-docker-containers/}"
|
||||
@online{chrootRestrictions,
|
||||
title = {Is chroot a security feature?},
|
||||
author = {March 27, 2013Josh Bressers},
|
||||
year = {2023},
|
||||
url = {https://www.redhat.com/en/blog/chroot-security-feature}
|
||||
}
|
||||
|
||||
@misc{gVisor,
|
||||
title={The Container Security Platform},
|
||||
author={Google},
|
||||
howpublished="\url{https://gvisor.dev/}"
|
||||
@online{dockerhub,
|
||||
title = {Build and Ship any Application Anywhere},
|
||||
author = {Docker},
|
||||
url = {https://hub.docker.com/},
|
||||
}
|
||||
|
||||
@misc{ibmVirtualizationDefinition,
|
||||
title={What is virtualization?},
|
||||
author={IBM},
|
||||
howpublished="\url{https://www.ibm.com/topics/virtualization}"
|
||||
@online{quay,
|
||||
title = {Quay builds, analyzes, distributes your container images},
|
||||
author = {Red Hat},
|
||||
url = {https://quay.io/},
|
||||
}
|
||||
|
||||
@misc{redhatVirtualization,
|
||||
title={What is virtualization?},
|
||||
author={Red Hat},
|
||||
year={2018},
|
||||
howpublished="\url{https://www.redhat.com/en/topics/virtualization/what-is-virtualization}"
|
||||
@online{oci,
|
||||
title = {Open Container Initiative},
|
||||
author = {The Linux Foundation},
|
||||
url = {https://opencontainers.org/},
|
||||
}
|
||||
|
||||
@misc{suseParavirtualizationDefinition,
|
||||
title={Paravirtualization},
|
||||
author={SUSE},
|
||||
howpublished="\url{https://www.suse.com/suse-defines/definition/paravirtualization/}"
|
||||
@online{LXCvsDocker2,
|
||||
title = {The Untold Story: Containers Before Docker's Rise - The LXC Revolution},
|
||||
author = {Dinesh Patil},
|
||||
year = {2023},
|
||||
url = {https://www.linkedin.com/pulse/untold-story-containers-before-dockers-rise-lxc-revolution-patil}
|
||||
}
|
||||
|
||||
@misc{geeksforgeeksParavirtualizationDefinition,
|
||||
title={Difference between Full Virtualization and Paravirtualization},
|
||||
author={GeeksforGeeks},
|
||||
howpublished="\url{https://www.geeksforgeeks.org/difference-between-full-virtualization-and-paravirtualization/}"
|
||||
@online{Hyperjacking,
|
||||
title = {What Is Hyperjacking? How to Prevent Hyperjacking on a VM},
|
||||
author = {Allan Jay Monteclaro},
|
||||
year = {2023},
|
||||
url = {https://www.serverwatch.com/virtualization/hyperjacking/}
|
||||
}
|
||||
|
||||
@misc{ParavirtualizationSecurity,
|
||||
title={Why Your Virtual Servers May be More Secure Than Their Physical Counterparts},
|
||||
author={Andrew Mallett},
|
||||
howpublished="\url{https://ine.com/blog/why-your-virtual-servers-may-be-more-secure-than-their-physical-counterparts}"
|
||||
@online{waterfall,
|
||||
title = {Waterfall Methodology: A Comprehensive Guide},
|
||||
author = {ATLASSIAN},
|
||||
url = {https://www.atlassian.com/agile/project-management/waterfall-methodology}
|
||||
}
|
||||
|
||||
@misc{ParavirtualizationVmware,
|
||||
title={Understanding Full Virtualization, Paravirtualization and Hardware Assisted Virtualization},
|
||||
author={VMware},
|
||||
howpublished="\url{https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/VMware_paravirtualization.pdf}"
|
||||
@online{agile,
|
||||
title = {What Is Agile Project Management? The Ultimate Guide},
|
||||
author = {Lee Davis},
|
||||
year = {2022},
|
||||
url = {https://www.forbes.com/advisor/business/what-is-agile-project-management/}
|
||||
}
|
||||
|
||||
@article{arif2015virtualization,
|
||||
title={Virtualization security: analysis and open challenges},
|
||||
author={Arif, Muhammad and Shakeel, Haroon},
|
||||
journal={International Journal of Hybrid Information Technology},
|
||||
volume={8},
|
||||
number={2},
|
||||
pages={237--246},
|
||||
year={2015}
|
||||
@online{devops,
|
||||
title = {DevOps},
|
||||
author = {Synopsys},
|
||||
url = {https://www.synopsys.com/glossary/what-is-devops.html}
|
||||
}
|
||||
|
||||
@inproceedings{wen2008sevmm,
|
||||
title={Sevmm: Vmm-based security control model},
|
||||
author={Wen-Zhi, Chen and Hong-Wei, Zhu and Wei, Huang},
|
||||
booktitle={2008 International Conference on Cyberworlds},
|
||||
pages={820--823},
|
||||
year={2008},
|
||||
organization={IEEE}
|
||||
@online{cicd,
|
||||
title = {What is CI/CD?},
|
||||
author = {GitLab},
|
||||
url = {https://about.gitlab.com/topics/ci-cd/}
|
||||
}
|
||||
|
||||
@misc{ibmHypervisorDefinition,
|
||||
title={What are hypervisors?},
|
||||
author={IBM},
|
||||
howpublished="\url{https://www.ibm.com/topics/hypervisors}"
|
||||
@online{caas,
|
||||
title = {What is CaaS?},
|
||||
author = {Sumo Logic},
|
||||
url = {https://www.sumologic.com/glossary/caas/}
|
||||
}
|
||||
|
||||
@misc{ibmContainerizationDefinition,
|
||||
title={What is containerization?},
|
||||
author={IBM},
|
||||
howpublished="\url{https://www.ibm.com/topics/containerization}"
|
||||
@online{caasVsIaas,
|
||||
title = {Container as a Service: The Basics and Top 4 Providers},
|
||||
author = {aquasec},
|
||||
year = {2023},
|
||||
url = {https://www.aquasec.com/cloud-native-academy/container-platforms/container-as-a-service/}
|
||||
}
|
||||
|
||||
@misc{ibmContainerSurvey,
|
||||
title={Containers in the enterprise},
|
||||
author={IBM},
|
||||
howpublished="\url{https://www.ibm.com/downloads/cas/VG8KRPRM}"
|
||||
@online{howCaasWorks,
|
||||
title = {The Guide to Containers-as-a-Service (CaaS)},
|
||||
author = {Karim Traiaia},
|
||||
year = {2023},
|
||||
url = {https://www.kerno.io/blog/containers-as-a-service-caas}
|
||||
}
|
||||
|
||||
@misc{ibmContainerVsVm,
|
||||
title={Containers vs. Virtual Machines (VMs): What’s the Difference?},
|
||||
author={IBM},
|
||||
howpublished="\url{https://www.ibm.com/blog/containers-vs-vms/}"
|
||||
@online{multiCloud,
|
||||
title = {What Is Multi-Cloud? Features, Architecture, Pros \& Cons},
|
||||
author = {Sarim Javaid},
|
||||
year = {2023},
|
||||
url = {https://www.cloudways.com/blog/what-is-multi-cloud/}
|
||||
}
|
||||
|
||||
@misc{ciaTriad,
|
||||
title={What is the CIA triad (confidentiality, integrity and availability)?},
|
||||
author={Wesley Chai},
|
||||
howpublished="\url{https://www.techtarget.com/whatis/definition/Confidentiality-integrity-and-availability-CIA}"
|
||||
@online{containerSecurity,
|
||||
title = {Containers or virtual machines: Which is more secure? The answer will surprise you},
|
||||
author = {Steven Vaughan-Nichols},
|
||||
year = {2018},
|
||||
url = {https://www.zdnet.com/article/which-is-more-secure-containers-or-virtual-machines-the-answer-will-surprise-you/}
|
||||
}
|
||||
|
||||
@misc{redhatVirtualizationDefinition,
|
||||
title={Understanding virtualization},
|
||||
author={Red Hat},
|
||||
howpublished="\url{https://www.redhat.com/en/topics/virtualization}"
|
||||
@online{containerSecurityExplained,
|
||||
title = {Containers and Cloud Security},
|
||||
author = {James Bottomley},
|
||||
year = {2018},
|
||||
url = {https://blog.hansenpartnership.com/containers-and-cloud-security/}
|
||||
}
|
||||
|
||||
@misc{redhatContainerVsVm,
|
||||
title={Containers vs VMs},
|
||||
author={Red Hat},
|
||||
year={2020},
|
||||
howpublished="\url{https://www.redhat.com/en/topics/containers/containers-vs-vms}"
|
||||
@online{containerEscapeTechniques,
|
||||
title = {7 Ways to Escape a Container},
|
||||
author = {Ori Abargil},
|
||||
year = {2023},
|
||||
url = {https://www.panoptica.app/research/7-ways-to-escape-a-container}
|
||||
}
|
||||
|
||||
@misc{dockerAlternatives,
|
||||
title={What Are The Best Docker Alternatives in 2022?},
|
||||
author={Cody Slingerland},
|
||||
year={2022},
|
||||
howpublished="\url{https://www.cloudzero.com/blog/docker-alternatives/}"
|
||||
@online{saasPricingModel,
|
||||
title = {Our guide to every SaaS pricing model},
|
||||
author = {vendr},
|
||||
year = {2022},
|
||||
url = {https://www.vendr.com/blog/saas-pricing-model#value-based-saas-pricing-models}
|
||||
}
|
||||
|
||||
@online{paasPricingModel,
|
||||
title = {PaaS (Platform-as-a-Service) - definition \& overview},
|
||||
author = {Sumo Logic},
|
||||
url = {https://www.sumologic.com/glossary/paas/}
|
||||
}
|
||||
|
||||
@online{cloudDeploymentModels,
|
||||
title = {An Overview of Cloud Deployment Models},
|
||||
author = {Intel},
|
||||
url = {https://www.intel.com/content/www/us/en/cloud-computing/deployment-models.html}
|
||||
}
|
||||
|
||||
@online{redhatVirtualizationManagement,
|
||||
title = {What is virtualization management?},
|
||||
author = {Red Hat},
|
||||
year = {2018},
|
||||
url = {https://www.redhat.com/en/topics/virtualization/what-is-virtualization-management}
|
||||
}
|
||||
|
||||
@online{phoenixnapHypervisors,
|
||||
title = {What is a Hypervisor? Types of Hypervisors 1 \& 2},
|
||||
author = {Sofija Simic},
|
||||
year = {2022},
|
||||
url = {https://phoenixnap.com/kb/what-is-hypervisor-type-1-2}
|
||||
}
|
||||
|
||||
@online{amazonHypervisors,
|
||||
title = {What’s the Difference Between Type 1 and Type 2 Hypervisors?},
|
||||
author = {Amazon Web Services},
|
||||
url = {https://aws.amazon.com/compare/the-difference-between-type-1-and-type-2-hypervisors/}
|
||||
}
|
||||
|
||||
@online{vmfailover,
|
||||
title = {What Is a Failover? Clustering and Replication Use Cases},
|
||||
author = {NAKIVO Team},
|
||||
year = {2023},
|
||||
url = {https://www.nakivo.com/blog/vm-failover-guide/}
|
||||
}
|
||||
|
||||
@online{kvm,
|
||||
title = {What is KVM?},
|
||||
author = {Red Hat},
|
||||
year = {2022},
|
||||
url = {https://www.redhat.com/en/topics/virtualization/what-is-KVM}
|
||||
}
|
||||
|
||||
@online{dataVirtualization,
|
||||
title = {Data Virtualization: Process, Components, Benefits, and Available Tools},
|
||||
author = {altexsoft},
|
||||
year = {2021},
|
||||
url = {https://www.altexsoft.com/blog/data-virtualization/}
|
||||
}
|
||||
|
||||
@online{desktopVirtualization,
|
||||
title = {What is Desktop Virtualization?},
|
||||
author = {VMware},
|
||||
url = {https://www.vmware.com/topics/glossary/content/desktop-virtualization.html}
|
||||
}
|
||||
|
||||
@online{redhatNFV,
|
||||
title = {What is NFV?},
|
||||
author = {Red Hat},
|
||||
year = {2019},
|
||||
url = {https://www.redhat.com/en/topics/virtualization/what-is-nfv}
|
||||
}
|
||||
|
||||
@online{vmwareMemoryVirtualization,
|
||||
title = {Memory Virtualization},
|
||||
author = {VMware},
|
||||
year = {2019},
|
||||
url = {https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-6E85F6DE-7365-4C28-B902-725D3C76C2E6.html}
|
||||
}
|
||||
|
||||
@online{codingninjasMemoryVirtualization,
|
||||
title = {Processor and Memory Virtualization},
|
||||
author = {Rajat Agrawal},
|
||||
year = {2023},
|
||||
url = {https://www.codingninjas.com/studio/library/processor-and-memory-virtualization}
|
||||
}
|
||||
|
||||
@online{ubackupStorageVirtualization,
|
||||
title = {What Is Storage Virtualization | Introduction and Implementation},
|
||||
author = {Crystal},
|
||||
year = {2022},
|
||||
url = {https://www.ubackup.com/enterprise-backup/storage-virtualization-jkzbj.html}
|
||||
}
|
||||
|
||||
@online{unixarenaVirtualization,
|
||||
title = {Virtualization & Hypervisor – Basic Interview Questions},
|
||||
author = {LINGESH},
|
||||
year = {2019},
|
||||
url = {https://www.unixarena.com/2019/08/virtualization-hypervisor-basic-interview-questions.html/}
|
||||
}
|
||||
|
||||
@online{cloudinfraStorageVirtualization,
|
||||
title = {Storage Virtualization in Cloud Computing – How it Works (Use Cases)},
|
||||
author = {Dennis Muvaa},
|
||||
url = {https://cloudinfrastructureservices.co.uk/storage-virtualization-in-cloud-computing-how-it-works-use-cases/}
|
||||
}
|
||||
|
||||
@online{tutorialsPointVirtualization,
|
||||
title = {Virtualization 2.0 - Overview},
|
||||
author = {Tutorials Point},
|
||||
url = {https://www.tutorialspoint.com/virtualization2.0/virtualization2.0_overview.htm}
|
||||
}
|
||||
|
||||
@online{geeksforgeeksApplicationVirtualization,
|
||||
title = {Virtualisation with Docker Containers},
|
||||
author = {GeeksforGeeks},
|
||||
year = {2023},
|
||||
url = {https://www.geeksforgeeks.org/virtualisation-with-docker-containers/}
|
||||
}
|
||||
|
||||
@online{mediumVirtualization,
|
||||
title = {Virtualization in Cloud Computing: Bridging the Gap Between Resources and Efficiency},
|
||||
author = {TechClaw},
|
||||
url = {https://medium.com/@techclaw/virtualization-in-cloud-computing-bridging-the-gap-between-resources-and-efficiency-3c5a9c65981e}
|
||||
}
|
||||
|
||||
@online{insightsForProfessionalsParavirtualization,
|
||||
title = {Paravirtualization vs. Full Virtualization: Pros and Cons},
|
||||
author = {Insights for Professionals},
|
||||
year = {2022},
|
||||
url = {https://www.insightsforprofessionals.com/it/data-center/paravirtualization-alternative-full-virtualization}
|
||||
}
|
||||
|
||||
@online{blackberryParavirtualization,
|
||||
title = {Paravirtualization},
|
||||
author = {BlackBerry},
|
||||
url = {https://blackberry.qnx.com/en/ultimate-guides/automotive-hypervisor/paravirtualization}
|
||||
}
|
||||
|
||||
@online{serverWatchParavirtualization,
|
||||
title = {What Is Paravirtualization? Definition and Uses},
|
||||
author = {Ray Fernandez},
|
||||
year = {2023},
|
||||
url = {https://www.serverwatch.com/virtualization/what-is-paravirtualization/}
|
||||
}
|
||||
|
||||
@online{vmblogParavirtualization,
|
||||
title = {What Are the Benefits of Paravirtualization?},
|
||||
author = {David Marshall},
|
||||
year = {2019},
|
||||
url = {https://vmblog.com/archive/2019/07/23/what-are-the-benefits-of-paravirtualization.aspx}
|
||||
}
|
||||
|
||||
@online{servermaniaParavirtualization,
|
||||
title = {What is Paravirtualization in Cloud Computing?},
|
||||
author = {Milad Karimyar},
|
||||
year = {2023},
|
||||
url = {https://blog.servermania.com/what-is-paravirtualization}
|
||||
}
|
||||
|
||||
@online{vmSnapshots,
|
||||
title = {Understanding the Correct Use of VM Snapshots},
|
||||
author = {Nicolette Carklin},
|
||||
year = {2021},
|
||||
url = {https://www.parallels.com/blogs/ras/vm-snapshot/}
|
||||
}
|
||||
|
||||
@online{techtargetHypervisorSecurity,
|
||||
title = {Virtual security tactics for Type 1 and Type 2 hypervisors},
|
||||
author = {Stephen J. Bigelow},
|
||||
year = {2013},
|
||||
url = {https://www.techtarget.com/searchitoperations/answer/Virtual-security-tactics-for-Type-1-and-Type-2-hypervisors}
|
||||
}
|
||||
|
||||
@online{hostitsmartMemoryVirtualization,
|
||||
title = {Memory Virtualization in Cloud Computing},
|
||||
author = {Host IT Smart},
|
||||
url = {https://www.hostitsmart.com/blog/memory-virtualization-in-cloud-computing/}
|
||||
}
|
||||
|
||||
@online{petriMemoryVirtualization,
|
||||
title = {Intro to Virtualization: Hardware, Software, Memory, Storage, Data and Network Virtualization Defined},
|
||||
author = {Bill Hill},
|
||||
year = {2012},
|
||||
url = {https://petri.com/intro-to-virtualization/}
|
||||
}
|
||||
|
||||
@online{containerEscapeRepercussions,
|
||||
title = {5 security concerns when using Docker},
|
||||
author = {Adrian Mouat},
|
||||
year = {2016},
|
||||
url = {https://www.oreilly.com/content/five-security-concerns-when-using-docker/}
|
||||
}
|
||||
|
||||
@online{kubernetes,
|
||||
title = {What is Kubernetes?},
|
||||
author = {Justin Ellingwood},
|
||||
year = {2018},
|
||||
url = {https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes}
|
||||
}
|
||||
|
||||
@online{dockerSwarm,
|
||||
title = {What is Docker Swarm: Modes, Example and Working},
|
||||
author = {Simplilearn},
|
||||
year = {2023},
|
||||
url = {https://www.simplilearn.com/tutorials/docker-tutorial/docker-swarm}
|
||||
}
|
||||
|
||||
@online{Yathi2017Hardening,
|
||||
title = {Hardening Docker containers, images, and host - security toolkit},
|
||||
author = {Yathi Naik},
|
||||
year = {2017},
|
||||
url = {https://cloud.redhat.com/blog/hardening-docker-containers-images-and-host-security-toolkit}
|
||||
}
|
||||
|
||||
@online{StackRox2019Docker,
|
||||
title = {Docker Container Security 101: Risks and 33 Best Practices},
|
||||
author = {StackRox},
|
||||
year = {2019},
|
||||
url = {https://www.stackrox.io/blog/docker-security-101/}
|
||||
}
|
||||
|
||||
@online{Marcin2019Hardening,
|
||||
title = {Hardening Docker Quick Tips},
|
||||
author = {Marcin Teodorczyk},
|
||||
year = {2019},
|
||||
url = {https://medium.com/intive-developers/hardening-docker-quick-tips-54ca9c283964}
|
||||
}
|
||||
|
||||
@online{deviceWhitelistController,
|
||||
title = {Device Whitelist Controller},
|
||||
author = {The Linux kernel user’s and administrator’s guide},
|
||||
url = {https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html}
|
||||
}
|
||||
|
||||
@online{dockerInherentSecurity,
|
||||
title = {The Inherent Security Benefits of Docker Containers},
|
||||
author = {Christopher Tozzi},
|
||||
url = {https://cloudnativenow.com/features/security-benefits-docker-containers/}
|
||||
}
|
||||
|
||||
@online{gVisor,
|
||||
title = {The Container Security Platform},
|
||||
author = {Google},
|
||||
url = {https://gvisor.dev/}
|
||||
}
|
||||
|
||||
@online{ibmVirtualizationDefinition,
|
||||
title = {What is virtualization?},
|
||||
author = {IBM},
|
||||
url = {https://www.ibm.com/topics/virtualization}
|
||||
}
|
||||
|
||||
@online{redhatVirtualization,
|
||||
title = {What is virtualization?},
|
||||
author = {Red Hat},
|
||||
year = {2018},
|
||||
url = {https://www.redhat.com/en/topics/virtualization/what-is-virtualization}
|
||||
}
|
||||
|
||||
@online{suseParavirtualizationDefinition,
|
||||
title = {Paravirtualization},
|
||||
author = {SUSE},
|
||||
url = {https://www.suse.com/suse-defines/definition/paravirtualization/}
|
||||
}
|
||||
|
||||
@online{geeksforgeeksParavirtualizationDefinition,
|
||||
title = {Difference between Full Virtualization and Paravirtualization},
|
||||
author = {GeeksforGeeks},
|
||||
url = {https://www.geeksforgeeks.org/difference-between-full-virtualization-and-paravirtualization/}
|
||||
}
|
||||
|
||||
@online{geeksforgeeksHardwareAssistedVirtualization,
|
||||
title = {Hardware Based Virtualization},
|
||||
author = {GeeksforGeeks},
|
||||
url = {https://www.geeksforgeeks.org/hardware-based-virtualization/}
|
||||
}
|
||||
|
||||
@online{sysdigContainerRuntime,
|
||||
title = {What are Container Runtimes?},
|
||||
author = {Sysdig},
|
||||
url = {https://sysdig.com/learn-cloud-native/container-security/what-are-container-runtimes/}
|
||||
}
|
||||
|
||||
@online{redhatContainerRuntime,
|
||||
title = {How Kubernetes creates and runs containers: An illustrated guide},
|
||||
author = {Bob Reselman},
|
||||
year = {2022},
|
||||
url = {https://www.redhat.com/architect/how-kubernetes-creates-runs-containers}
|
||||
}
|
||||
|
||||
@online{codemotionContainerImages,
|
||||
title = {Container Images: Technical Refresher and Security Best Practices},
|
||||
author = {Gilad David Maayan},
|
||||
year = {2023},
|
||||
url = {https://www.codemotion.com/magazine/cybersecurity/container-images-technical-refresher-and-security-best-practices/}
|
||||
}
|
||||
|
||||
@online{osVirtualizationInfo,
|
||||
title = {OS-Level Virtualization},
|
||||
author = {Vikas Jain, Vibha Goyal, Nitin Kundapur Bhat},
|
||||
year = {2016},
|
||||
url = {https://courses.engr.illinois.edu/cs423/sp2016/lectures/VirtOS.pdf}
|
||||
}
|
||||
|
||||
@online{teimouriOsVirtualizationDefinition,
|
||||
title = {Operating-system-level virtualization},
|
||||
author = {Davoud Teimouri},
|
||||
year = {2017},
|
||||
url = {https://www.teimouri.net/operating-system-level-virtualization/}
|
||||
}
|
||||
|
||||
@online{webopediaOsVirtualizationDefinition,
|
||||
title = {Operating System-Level Virtualization},
|
||||
author = {Vangie Beal},
|
||||
year = {2021},
|
||||
url = {https://www.webopedia.com/definitions/operating-system-level-virtualization/}
|
||||
}
|
||||
|
||||
@online{ParavirtualizationSecurity,
|
||||
title = {Why Your Virtual Servers May be More Secure Than Their Physical Counterparts},
|
||||
author = {Andrew Mallett},
|
||||
year = {2019},
|
||||
url = {https://ine.com/blog/why-your-virtual-servers-may-be-more-secure-than-their-physical-counterparts}
|
||||
}
|
||||
|
||||
@online{ParavirtualizationVmware,
|
||||
title = {Understanding Full Virtualization, Paravirtualization and Hardware Assisted Virtualization},
|
||||
author = {VMware},
|
||||
year = {2007},
|
||||
url = {https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/VMware_paravirtualization.pdf}
|
||||
}
|
||||
|
||||
@online{awsMicroservices,
|
||||
title = {What are Microservices?},
|
||||
author = {AWS},
|
||||
url = {https://aws.amazon.com/microservices/}
|
||||
}
|
||||
|
||||
@online{cloudzeroScalability,
|
||||
title = {Horizontal Vs. Vertical Scaling: How Do They Compare?},
|
||||
author = {Cody Slingerland},
|
||||
year = {2023},
|
||||
url = {https://www.cloudzero.com/blog/horizontal-vs-vertical-scaling/}
|
||||
}
|
||||
|
||||
@online{abacusFullParaOSVirtualization,
|
||||
title = {Three Types of Server Virtualization Explained},
|
||||
author = {Abacus},
|
||||
url = {https://goabacus.com/three-types-of-server-virtualization-explained/}
|
||||
}
|
||||
|
||||
@online{ibmHypervisorDefinition,
|
||||
title = {What are hypervisors?},
|
||||
author = {IBM},
|
||||
url = {https://www.ibm.com/topics/hypervisors}
|
||||
}
|
||||
|
||||
@online{ibmContainerizationDefinition,
|
||||
title = {What is containerization?},
|
||||
author = {IBM},
|
||||
url = {https://www.ibm.com/topics/containerization}
|
||||
}
|
||||
|
||||
@online{ibmContainerSurvey,
|
||||
title = {Containers in the enterprise},
|
||||
author = {IBM},
|
||||
url = {https://www.ibm.com/downloads/cas/VG8KRPRM}
|
||||
}
|
||||
|
||||
@online{ibmContainerVsVm,
|
||||
title = {Containers vs. Virtual Machines (VMs): What’s the Difference?},
|
||||
author = {IBM},
|
||||
url = {https://www.ibm.com/blog/containers-vs-vms/}
|
||||
}
|
||||
|
||||
@online{ciaTriad,
|
||||
title = {What is the CIA triad (confidentiality, integrity and availability)?},
|
||||
author = {Wesley Chai},
|
||||
url = {https://www.techtarget.com/whatis/definition/Confidentiality-integrity-and-availability-CIA}
|
||||
}
|
||||
|
||||
@online{redhatVirtualizationDefinition,
|
||||
title = {Understanding virtualization},
|
||||
author = {Red Hat},
|
||||
url = {https://www.redhat.com/en/topics/virtualization}
|
||||
}
|
||||
|
||||
@online{redhatContainerVsVm,
|
||||
title = {Containers vs VMs},
|
||||
author = {Red Hat},
|
||||
year = {2020},
|
||||
url = {https://www.redhat.com/en/topics/containers/containers-vs-vms}
|
||||
}
|
||||
|
||||
@online{dockerAlternatives,
|
||||
title = {What Are The Best Docker Alternatives in 2022?},
|
||||
author = {Cody Slingerland},
|
||||
year = {2022},
|
||||
url = {https://www.cloudzero.com/blog/docker-alternatives/}
|
||||
}
|
||||
|
||||
@article{yasrab2018mitigating,
|
||||
title={Mitigating docker security issues},
|
||||
author={Yasrab, Robail},
|
||||
journal={arXiv preprint arXiv:1804.05039},
|
||||
year={2018}
|
||||
title = {Mitigating docker security issues},
|
||||
author = {Yasrab, Robail},
|
||||
year = {2018},
|
||||
journal = {arXiv preprint arXiv:1804.05039}
|
||||
}
|
||||
|
||||
@misc{ansible,
|
||||
title={Ansible},
|
||||
author={Red Hat},
|
||||
howpublished="\url{https://www.ansible.com/}"
|
||||
@online{ansible,
|
||||
title = {Ansible},
|
||||
author = {Red Hat},
|
||||
url = {https://www.ansible.com/}
|
||||
}
|
||||
|
||||
@misc{terraform,
|
||||
title={Terraform},
|
||||
author={HashiCorp},
|
||||
howpublished="\url{https://www.terraform.io/}"
|
||||
@online{terraform,
|
||||
title = {Terraform},
|
||||
author = {HashiCorp},
|
||||
url = {https://www.terraform.io/}
|
||||
}
|
||||
|
||||
@article{mell2011nist,
|
||||
title={The NIST definition of cloud computing},
|
||||
author={Mell, Peter and Grance, Tim and others},
|
||||
year={2011},
|
||||
publisher={Computer Security Division, Information Technology Laboratory, National~…}
|
||||
title = {The NIST Definition of Cloud Computing},
|
||||
author = {Peter Mell and Timothy Grance},
|
||||
year = {2011},
|
||||
month = {2011-09-28},
|
||||
publisher = {Special Publication (NIST SP), National Institute of Standards and Technology, Gaithersburg, MD},
|
||||
doi = {https://doi.org/10.6028/NIST.SP.800-145},
|
||||
language = {en},
|
||||
}
|
||||
|
||||
@misc{AkihiroSuda,
|
||||
@online{AkihiroSuda,
|
||||
author = {Akihiro Suda},
|
||||
title = {rootlesskit},
|
||||
year = {2020},
|
||||
publisher = {GitHub},
|
||||
journal = {GitHub repository},
|
||||
howpublished = {\url{https://github.com/rootless-containers/rootlesskit}},
|
||||
url = {https://github.com/rootless-containers/rootlesskit}
|
||||
}
|
||||
|
||||
@inproceedings{reshetova2014security,
|
||||
title={Security of OS-level virtualization technologies},
|
||||
author={Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
|
||||
booktitle={Nordic Conference on Secure IT Systems},
|
||||
pages={77--93},
|
||||
year={2014},
|
||||
organization={Springer}
|
||||
title = {Security of OS-level virtualization technologies},
|
||||
author = {Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
|
||||
booktitle = {Nordic Conference on Secure IT Systems},
|
||||
pages = {77--93},
|
||||
year = {2014},
|
||||
organization = {Springer}
|
||||
}
|
||||
|
||||
@online{enisaSecurityOfVirtualization,
|
||||
title = {Security aspects of virtualization},
|
||||
author = {ENISA},
|
||||
year = {2017},
|
||||
url = {https://www.enisa.europa.eu/publications/security-aspects-of-virtualization}
|
||||
}
|
||||
|
||||
@article{arif2015virtualization,
|
||||
title = {Virtualization security: analysis and open challenges},
|
||||
author = {Arif, Muhammad and Shakeel, Haroon},
|
||||
journal = {International Journal of Hybrid Information Technology},
|
||||
volume = {8},
|
||||
number = {2},
|
||||
pages = {237--246},
|
||||
year = {2015}
|
||||
}
|
||||
|
||||
@inproceedings{wen2008sevmm,
|
||||
title = {Sevmm: Vmm-based security control model},
|
||||
author = {Wen-Zhi, Chen and Hong-Wei, Zhu and Wei, Huang},
|
||||
booktitle = {2008 International Conference on Cyberworlds},
|
||||
pages = {820--823},
|
||||
year = {2008},
|
||||
organization = {IEEE}
|
||||
}
|
||||
|
||||
@inproceedings{virtualizationSecurity,
|
||||
author = {Sane, Bernard and Niang, Ibrahima and Fall, Doudou},
|
||||
year = {2018},
|
||||
month = {12},
|
||||
pages = {1317-1322},
|
||||
title = {A Review of Virtualization, Hypervisor and VM Allocation Security: Threats, Vulnerabilities, and Countermeasures},
|
||||
doi = {10.1109/CSCI46756.2018.00255}
|
||||
}
|
||||
|
||||
@article{Aalam_2021,
|
||||
doi = {10.1088/1742-6596/1950/1/012027},
|
||||
url = {https://dx.doi.org/10.1088/1742-6596/1950/1/012027},
|
||||
year = {2021},
|
||||
month = {aug},
|
||||
publisher = {IOP Publishing},
|
||||
volume = {1950},
|
||||
number = {1},
|
||||
pages = {012027},
|
||||
author = {Zunaid Aalam and Vinod Kumar and Surendra Gour},
|
||||
title = {A review paper on hypervisor and virtual machine security},
|
||||
journal = {Journal of Physics: Conference Series},
|
||||
}
|
||||
|
||||
@online{geeksforgeeksVirtualizationSecurityGoodPractices,
|
||||
title = {Hypervisor Security in Cloud Computing},
|
||||
author = {GeeksforGeeks},
|
||||
year = {2023},
|
||||
url = {https://www.geeksforgeeks.org/hypervisor-security-in-cloud-computing/}
|
||||
}
|
||||
|
||||
@online{accessAuthorizationPlugin,
|
||||
title = {Access authorization plugin},
|
||||
author = {Docker},
|
||||
url = {https://docs.docker.com/engine/extend/plugins_authorization/#access-authorization-plugin}
|
||||
}
|
||||
|
||||
@online{podman,
|
||||
title = {What is Podman?},
|
||||
author = {Red Hat},
|
||||
year = {2022},
|
||||
url = {https://www.redhat.com/en/topics/containers/what-is-podman}
|
||||
}
|
||||
|
||||
@online{containerdRunc,
|
||||
title = {The differences between Docker, containerd, CRI-O and runc},
|
||||
author = {Tom Donohue},
|
||||
year = {2023},
|
||||
url = {https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/}
|
||||
}
|
||||
|
||||
@online{containerOSlimitations,
|
||||
title = {Virtualization vs. Containerization — Comparing Differences},
|
||||
author = {Liquid Web},
|
||||
year = {2023},
|
||||
url = {https://www.liquidweb.com/kb/virtualization-vs-containerization/}
|
||||
}
|
||||
|
||||
@online{applicationContainerization,
|
||||
title = {Containerized Applications Overview},
|
||||
author = {Knowledge Center},
|
||||
url = {https://www.datadoghq.com/knowledge-center/containerized-applications/}
|
||||
}
|
||||
|
||||
@online{apparmor,
|
||||
title = {AppArmor},
|
||||
author = {AppArmor},
|
||||
url = {https://apparmor.net/}
|
||||
}
|
||||
|
||||
@online{selinux,
|
||||
title = {What is SELinux?},
|
||||
author = {Red Hat},
|
||||
year = {2019},
|
||||
url = {https://www.redhat.com/en/topics/linux/what-is-selinux}
|
||||
}
|
||||
|
||||
@online{seccomp,
|
||||
title = {Improving Linux container security with seccomp},
|
||||
author = {Valentin Rothberg},
|
||||
year = {2020},
|
||||
url = {https://www.redhat.com/sysadmin/container-security-seccomp}
|
||||
}
|
||||
|
||||
@@ -1,216 +1,666 @@
|
||||
\chapter{Εισαγωγή} \label{introduction}
|
||||
|
||||
Παραδοσιακά, όταν ήθελε κάποιος χρήστης/εταιρεία να παράσχει μια υπηρεσία, στο
|
||||
ευρύ κοινό θα έπρεπε να διαθέσει ένα ````Χ'''' κεφάλαιο για την αγορά
|
||||
εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή ετύγχανε ευρείας αποδοχής
|
||||
\noindent Παραδοσιακά, όταν κάποιος χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
|
||||
υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
|
||||
αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή ετύγχανε ευρείας αποδοχής,
|
||||
καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
|
||||
η μεταφορά όλων των υπαρχόντων πόρων λογισμικού (βάσεις δεδομένων
|
||||
(\textlatin{Databases}), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) σε
|
||||
αυτό. Η παραπάνω διαδικασία απαιτούσε επιπλέον κεφάλαιο και αρκετές εργατοώρες
|
||||
προκειμένου να γίνει πράξη. Στις αρχές του 2000 ο τρόπος διεξαγωγής της
|
||||
παραπάνω διαδικασίας άλλαξε ριζικά όταν η \textlatin{Amazon} για πρώτη φορά
|
||||
προσέφερε την υπηρεσία \textlatin{AWS}. Έπειτα, πολλές εταιρίες όπως η
|
||||
\textlatin{Google}, \textlatin{IBM} και \textlatin{Mirosoft} άρχισαν να
|
||||
προσφέρουν και αυτές υπηρεσίες τύπου \textlatin{IaaS}.
|
||||
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεις δεδομένων
|
||||
(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
|
||||
κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
|
||||
κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
|
||||
λειτουργία του εξοπλισμού και η συντήρηση του είχε κι αυτή ένα σημαντικό
|
||||
κόστος.
|
||||
|
||||
\section{\textlatin{Cloud Computing}} \label{cloudComputing}
|
||||
Στις αρχές του 2000 ο τρόπος διεξαγωγής της παραπάνω διαδικασίας άλλαξε ριζικά
|
||||
όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
|
||||
τομέα του ηλεκτρονικού εμπορίου (e-commerce), δημιούργησε την θυγατρική της,
|
||||
AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρεσίες
|
||||
νεφο-υπολογιστικής και συγκεκριμένα, την EC2 (Elastic Compute Cloud), μια
|
||||
υπηρεσία τύπου IaaS (Infrastructure as a Service). Πρόκειται για την πρώτη
|
||||
υπηρεσία ενοικίασης υπολογιστικών πόρων προς αξιοποίηση από οργανισμούς και
|
||||
επιχειρήσεις προκειμένου να επιταχυνθεί η διαδικασία διάθεσης των δικών τους
|
||||
υπηρεσιών. Αυτό το μοντέλο λειτουργίας παρέχει πολλά πλεονεκτήματα όπως το
|
||||
μικρότερο κόστος εκκίνησης διάθεσης υπηρεσιών, η διευκόλυνση κλιμάκωσης τους
|
||||
(είτε οριζόντιας όπου μοιράζεται ο φόρτος εργασίας σε παραπάνω διακομιστές είτε
|
||||
κάθετης κατά την οποία ένας διακομιστής αναβαθμίζεται με ισχυρότερες
|
||||
προδιαγραφές \footfullcite{cloudzeroScalability}) και η απαλλαγή ευθύνης
|
||||
σχετικά με την συνεχή λειτουργία του εξοπλισμού στον οποίο στεγάζονται.
|
||||
|
||||
Ο όρος \textlatin{Cloud Computing} δεν είναι καινούριος. Ήρθε στο προσκήνιο
|
||||
χάρη στην \textlatin{Amazon} όταν κοντά στο 2000 δημιούργησε τη θυγατρική της,
|
||||
\textlatin{AWS} ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε
|
||||
στον τομέα του \textlatin{e-commerce}. Από τότε πολλές εταιρίες όπως αυτές που
|
||||
προαναφέρθηκαν στο κεφάλαιο [\ref{introduction}] αλλά και άλλες όπως
|
||||
\textlatin{Linode}, \textlatin{Vultr} και \textlatin{Digital Ocean}, προσφέρουν
|
||||
\textlatin{Cloud Computing} ως την κύρια υπηρεσία τους δίνοντας τη δυνατότητα
|
||||
διάθεσης υπολογιστικών πόρων στους χρήστες με τη μορφή ενοικίασης ιδεατών
|
||||
μηχανών. Ο έλεγχος τους γίνεται μέσω ενός \textlatin{API} με το οποίο
|
||||
επικοινωνεί κανείς είτε μέσω γραφικού περιβάλλοντος από την ιστοσελίδα τους
|
||||
είτε μέσω της γραμμής εντολών.
|
||||
Λόγω της ευρείας αποδοχής της και των πολλών πλεονεκτημάτων που παρέχει, πολλές
|
||||
άλλες εταιρίες όπως η Google, IBM και Microsoft άρχισαν να προσφέρουν και αυτές
|
||||
υπηρεσίες ίδιου τύπου. Σήμερα, ο μέσος καταναλωτής έχει στην διάθεση του μια
|
||||
πληθώρα εταιριών που προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα
|
||||
μερικές από αυτές όπως η Linode, Vultr και Digital Ocean, προσφέρουν ως την
|
||||
κύρια υπηρεσία τους τη δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με
|
||||
τη μορφή ενοικίασης εικονικών μηχανών.
|
||||
|
||||
\section{\textlatin{Security of Cloud Computing}} \label{cloudComputingSecurity}
|
||||
\section{Νεφο-υπολογιστική} \label{cloudComputing}
|
||||
|
||||
Όταν επιλέξει κανείς να δημιουργήσει ιδεατές μηχανές μέσω μιας από τις διάφορες
|
||||
πλατφόρμες που το υποστηρίζουν, πολλές φορές για τη διευκόλυνση του χρήστη η
|
||||
διαδικασία γίνεται μέσω γραφικού περιβάλλοντος της μορφής \textlatin{Point and
|
||||
Click}. Τις περισσότερες φορές διατίθενται διάφορες διανομές \textlatin{Linux}
|
||||
οι οποίες έχουν εγκατεστημένα και ρυθμισμένα εκ των προτέρων διάφορα λογισμικά
|
||||
όπως \textlatin{MySQL} για διαχείριση βάσης δεδομένων και \textlatin{Nginx} για
|
||||
διακομιστή ιστού. Αυτό καθιστά πολύ πιο εύκολη τη διαδικασία στον χρήστη μιας
|
||||
και δε χρειάζεται να διαθέσει τον χρόνο εγκατάστασης και ρύθμισης τους αλλά
|
||||
εισάγει ένα αναγκαίο μοντέλο εμπιστοσύνης ανάμεσα σε αυτόν και όποιον έκανε τις
|
||||
ρυθμίσεις. Όπως αναφέρεται στο \textlatin{\citealt{balduzzi2012security}} και
|
||||
θα το δούμε και παρακάτω πολλές φορές αυτή η διαδικασία δε γίνεται σωστά και
|
||||
αφήνουν τον τελικό χρήστη και μερικές φορές ακόμα και τον πάροχο νέφους
|
||||
ευάλωτους σε ρίσκα ασφαλείας όπως μη εγκεκριμένη πρόσβαση, μόλυνση με κακόβουλο
|
||||
λογισμικό και υποκλοπές ευαίσθητων προσωπικών δεδομένων.
|
||||
Με τον όρο νεφο-υπολογιστική (Cloud Computing), αναφερόμαστε σε ένα μοντέλο
|
||||
παράδοσης υπολογιστικών πόρων κατά παραγγελία από μια επιχείρηση προς τους
|
||||
καταναλωτές της. Οι υπηρεσίες που προσφέρει χωρίζονται σε τρεις κατηγορίες. Η
|
||||
πρώτη, SaaS (Software as a Service) αναφέρεται στην διάθεση λογισμικού του
|
||||
οποίου οι λειτουργικές και μη λειτουργικές απαιτήσεις αποτελούν ευθύνη του
|
||||
παρόχου. Η κατηγορία PaaS (Platform as a Service) ορίζεται ως η διάθεση
|
||||
πλατφόρμας ανάπτυξης/εκτέλεσης λογισμικού όπου μονάχα οι μη λειτουργικές
|
||||
απαιτήσεις του καλύπτονται από τον πάροχο. Τέλος, η κατηγορία IaaS
|
||||
(Infrastructure as a Service) μεταφράζεται ως προσφορά απομακρυσμένων
|
||||
διακομιστών τους οποίους μια επιχείρηση μπορεί να αξιοποιήσει αναλόγως τις
|
||||
ανάγκες της ακολουθώντας φυσικά τους όρους και προϋποθέσεις του παρόχου. Τα
|
||||
πλεονεκτήματα που παρέχει η νεφο-υπολογιστική σε σχέση με την παραδοσιακή
|
||||
μέθοδο διάθεσης υπηρεσιών είναι αρκετά αλλά αυτά που ξεχωρίζουν από μεριάς των
|
||||
πελατών είναι η απόλυτη απαλλαγή ευθύνης των υποδομών νέφους, η απαράμιλλη
|
||||
ταχύτητα διάθεσης και κλιμάκωσης των υπηρεσιών και η εξάλειψη περιττού κόστους
|
||||
λόγω του ευέλικτου μοντέλου χρέωσης όπου προσμετρούνται μόνο οι πόροι που
|
||||
χρησιμοποιήθηκαν.
|
||||
|
||||
\section{\textlatin{Docker}} \label{docker}
|
||||
Σημαντικό ρόλο στην ευρεία αποδοχή των υπηρεσιών που προσφέρονται μέσω της
|
||||
νεφο-υπολογιστικής είχε η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
|
||||
μετέπειτα διαχείρισης τους. Σε κάθε περίπτωση γίνεται χρήση ενός API το οποίο
|
||||
είναι προσπελάσιμο έμμεσα μέσω ενός γραφικού περιβάλλοντος (self-service
|
||||
portal), εργαλείου γραμμής εντολών ή με προγραμματιστικό τρόπο (πχ. με τη χρήση
|
||||
SDKs (Software Development Kits)).
|
||||
|
||||
\subsection{Ο ρόλος του \textlatin{Docker}} \label{dockerRole}
|
||||
\section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}
|
||||
|
||||
Το \textlatin{Docker} είναι μια μηχανή δοχείων που επιτρέπει τον διαχωρισμό
|
||||
ανάμεσα στον πηγαίο κώδικα, τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από
|
||||
το κύριο σύστημα. Πρόκειται για μια πλατφόρμα που διαθέτει μηχανισμούς για
|
||||
συναρμολόγηση, θέση σε λειτουργία, εκτέλεση, ενημέρωση και διαχείριση των
|
||||
προγραμμάτων σε μορφή δοχείων.
|
||||
Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
|
||||
χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
|
||||
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη της
|
||||
εξαρτάται από 3 βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
|
||||
νέφους και στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
|
||||
νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
|
||||
που χρησιμοποιούνται όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
|
||||
τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους απομακρυσμένους
|
||||
διακομιστές του και ο τελικός χρήστης εάν προβεί στην χρήση δοχείων. Ο τρίτος
|
||||
και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες οφείλει να προβεί ο
|
||||
χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την ασφάλεια σύμφωνα με τις
|
||||
ανάγκες του.
|
||||
|
||||
Πολλά λειτουργικά συστήματα αλλά και αυτά που κάνουν χρήση του πυρήνα
|
||||
\textlatin{Linux} διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες
|
||||
εικονικοποίησης όπως είναι τα \textlatin{control groups} για την ενάθεση πόρων
|
||||
μεταξύ διεργασιών και \textlatin{namespaces} για τον περιορισμό πρόσβασης ή
|
||||
ορατότητας αυτών σε σχέση με άλλες διεργασίες ή περιοχές του συστήματος
|
||||
δημιουργώντας έτσι δοχεία.
|
||||
Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
|
||||
πλατφόρμες IaaS, προς διευκόλυνσή του η διαδικασία γίνεται και μέσω γραφικού
|
||||
περιβάλλοντος της μορφής Point and Click. Στις εικονικές μηχανές που
|
||||
προσφέρονται τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
|
||||
συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
|
||||
των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
|
||||
MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τρόπο, η διαδικασία
|
||||
δημιουργίας εικονικής μηχανής είναι αρκετά εύκολη για τον χρήστη, ο οποίος δεν
|
||||
χρειάζεται να έχει ειδικές γνώσεις στο υλικό για να το πετύχει αυτό. Στην
|
||||
προκειμένη περίπτωση, ενώ υπήρχε μηδενική δυσκολία για την απόκτηση εικονικής
|
||||
μηχανής εξοπλισμένης με λειτουργικό σύστημα και πιθανότατα απαραίτητα για τον
|
||||
χρήση προγράμματα, η ασφάλεια της δεν είναι πάντοτε εγγυημένη. Πολλά από τα
|
||||
προγράμματα που θα χρησιμοποιήσει ο χρήστης δεν παρέχουν εξαρχής
|
||||
ενεργοποιημένες τις παραμέτρους ασφαλείας που μπορεί να υποστηρίζουν διότι δεν
|
||||
δύναται να υπάρχει μια ασφαλής ρύθμιση που να καλύπτει όλα τα πιθανά σενάρια
|
||||
χρήσης. Επιπλέον, η ρύθμιση των παραμέτρων ασφαλείας είναι μια διαδικασία που
|
||||
απαιτεί εξειδικευμένες γνώσεις και είναι αρκετά εύκολο όχι μόνο να παραλειφθεί
|
||||
αλλά και να γίνει λανθασμένα λόγω έλλειψης οικειότητας με τα εργαλεία που έχει
|
||||
στην διάθεση του.
|
||||
|
||||
\pagebreak
|
||||
Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
|
||||
που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
|
||||
ρυθμισμένα εκ τω προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
|
||||
όπου υπάρχει τυφλή εμπιστοσύνη προς την ορθότητα των ρυθμίσεων αυτών σε
|
||||
συνδυασμό με έλλειψη γνώσης των εργαλείων, ενδέχεται λόγω ανθρώπινου λάθους ή
|
||||
στοχευμένα, να μένει ο τελικός χρήστης ευάλωτος σε ρίσκα ασφαλείας όπως μη
|
||||
εξουσιοδοτημένη πρόσβαση, μόλυνση με κακόβουλο λογισμικό και υποκλοπές
|
||||
ευαίσθητων προσωπικών δεδομένων. Στην περίπτωση που και ο πάροχος νέφους έχει
|
||||
παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
|
||||
εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
|
||||
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking
|
||||
\footfullcite{Hyperjacking} και να αποκτήσει έλεγχο του υπερ-επόπτη με
|
||||
αποτέλεσμα να είναι σε θέση να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές
|
||||
μηχανές είτε στον διακομιστή στον οποίο εκτελείται.
|
||||
|
||||
\subsection{Πως προέκυψε} \label{dockerOrigins}
|
||||
\clearpage
|
||||
|
||||
Λόγω δυσκολίας αυτοματοποίησης της διαχείρισης των δοχείων αυτών δημιουργήθηκε
|
||||
το \textlatin{Docker} τη χρονολογία 2013 απλοποιώντας κατά πολύ την ανάπτυξη
|
||||
και παράδοση κατανεμημένων εφαρμογών. Οι λειτουργίες που προσφέρει, το
|
||||
καθιστούν την καταλληλότερη επιλογή για επιχειρήσεις που λειτουργούν με ένα
|
||||
υβριδικό μοντέλο νέφους και εγκαταστάσεων ή αποκλειστικά στο \textlatin{Cloud}.
|
||||
Το βασικότερο από τα πλεονεκτήματα του σε σχέση με παραδοσιακές εικονικές
|
||||
μηχανές είναι το γεγονός ότι όλα τα δοχεία μοιράζονται τον ίδιο πυρήνα και
|
||||
επομένως δε χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση ολόκληρου του
|
||||
λειτουργικού συστήματος. Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε κάθε
|
||||
περιβάλλον που έχει εγκατεστημένο το \textlatin{Docker} και πολύ ταχύτερα από
|
||||
μια εικονική μηχανή κάνοντας τα ιδανικά για \textlatin{CI/CD} αλλά και
|
||||
πρακτικές \textlatin{Agile} ή \textlatin{DevOps}. Τέλος, λόγω των δυνατοτήτων
|
||||
του προσφέρει μεγαλύτερη αποδοτικότητα πόρων αφού μπορεί κανείς να εκτελέσει
|
||||
πολύ περισσότερα αντίγραφα ενός προγράμματος σε σχέση με τον αριθμό που θα
|
||||
μπορούσε με χρήση ιδεατών μηχανών, κάτι που μειώνει ιδιαίτερα το κόστος
|
||||
λειτουργίας.
|
||||
\section{Εικονικοποίηση και τεχνολογίες υλοποίησης της} \label{virtualizationTechnologiesIntroduction}
|
||||
|
||||
\section{\textlatin{Why Docker}} \label{whyDocker}
|
||||
Η εικονικοποίηση είναι ένας όρος που χρησιμοποιούμε όταν θέλουμε να αναφερθούμε
|
||||
στην αναπαράσταση πόρων σε εικονική μορφή με σκοπό την αναδιαμόρφωση τους ούτως
|
||||
ώστε να ικανοποιούνται οι ανάγκες ενός συστήματος. Εφαρμόζεται σε μια πληθώρα
|
||||
πόρων όπως οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα δεδομένα. Η πιο
|
||||
συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η οποία αποτελεί
|
||||
και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να επιτευχθεί, απαιτείται η
|
||||
χρήση ενός υπερ-επόπτη. Ένα λογισμικό υπεύθυνο για την κατάτμηση των φυσικών
|
||||
πόρων ενός διακομιστή σε μια ή περισσότερες εικονικές αναπαραστάσεις ενός
|
||||
συνόλου αυτών με σκοπό να χρησιμοποιηθούν ως ξεχωριστοί διακομιστές.
|
||||
|
||||
Η δημοτικότητα του έχει συνταυτίσει τους όρους \textlatin{Docker} και
|
||||
\textlatin{Container}. Παρόλα αυτά ιστορικά, οι πρώτες τεχνολογίες περί δοχείων
|
||||
υπήρχαν πολύ πριν βγει στην αγορά. Συγκεκριμένα το 2008 εφαρμόστηκε στον πυρήνα
|
||||
του \textlatin{Linux} το \textlatin{LXC} που επέτρεπε πλήρη εικονικοποίηση ενός
|
||||
στιγμιότυπου \textlatin{Linux}, ενώ η εντολή \textlatin{chroot} που προϋπήρχε
|
||||
από το 1979 στην έβδομη έκδοση του \textlatin{Unix} έδινε τη δυνατότητα
|
||||
δημιουργίας και φιλοξενίας ενός ξεχωριστού εικονικού αντιγράφου του συστήματος
|
||||
λογισμικού.
|
||||
Για έναν υπερ-επόπτη υπάρχουν δύο κατηγορίες στις οποίες μπορεί να ανήκει. Είτε
|
||||
πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης με το
|
||||
υλικό, είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον
|
||||
υποκείμενο διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη είναι άμεσα
|
||||
εξαρτώμενη από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η ταχύτητα και η
|
||||
απόδοση είναι υψίστης σημασίας, η άμεση πρόσβαση του υπερ-επόπτη τύπου 1 στο
|
||||
υλικό συμβάλει στην επίτευξη της διατήρησης των δύο αυτών προδιαγραφών σε
|
||||
κατάλληλες τιμές. Από την άλλη, ένας υπερ-επόπτης τύπου 2 δεν έρχεται σε
|
||||
αντιπαράθεση με το υποκείμενο ΛΣ και επιτρέπει την χρήση προγραμμάτων που το ΛΣ
|
||||
πιθανόν να μην είναι σε θέση να εκτελέσει.
|
||||
|
||||
\section{\textlatin{Advantages Over LXC and other older technologies}} \label{advantagesOverLXC}
|
||||
\clearpage
|
||||
|
||||
Ενώ χρησιμοποιούνται ακόμα και στις μέρες μας, δεν προσφέρουν την ίδια
|
||||
διαφάνεια χρήσης αφού πολλές φορές αναφέρονται σε ρυθμίσεις συγκεκριμένες για
|
||||
την εκάστοτε συσκευή. Το \textlatin{Docker} ωστόσο, δίνει τη δυνατότητα
|
||||
κατασκευής μιας εφαρμογής που θα συνεχίσει να τρέχει ακόμα και αν κομμάτια της
|
||||
χρειάζονται επισκευή αφού πολλές διεργασίες συνδυάζονται σε ένα δοχείο.
|
||||
Διευκολύνει την κατασκευή δοχείων βάζοντας κριτήρια όπως τον κώδικα της
|
||||
εφαρμογής και κάθε ένα μπορεί να χρησιμοποιηθεί ως πρότυπο για τη δημιουργία
|
||||
καινούριου. Το πιο σημαντικό από όλα όμως είναι το γεγονός πως εξαιτίας της
|
||||
δημοτικότητας του, ο καθένας έχει πρόσβαση σε χιλιάδες δοχεία που ανέβασε
|
||||
κάποιος άλλος.
|
||||
Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
|
||||
επίτευξης της. Την πλήρη εικονικοποίηση και την παρα-εικονικοποίηση
|
||||
\footfullcite{abacusFullParaOSVirtualization}. Στην πρώτη περίπτωση το
|
||||
λειτουργικό σύστημα που εκτελείται στον εικονικό διακομιστή συμπεριφέρεται όπως
|
||||
θα συμπεριφερόταν σε έναν φυσικό διακομιστή. Αυτό συμβαίνει διότι από μεριάς
|
||||
του λειτουργικού συστήματος δεν υπάρχει επίγνωση της εικονικοποίησης που έχει
|
||||
λάβει μέρος για να δημιουργηθούν οι εικονικοί πόροι στους οποίους στεγάζεται. Η
|
||||
πλήρης εικονικοποίηση μπορεί να είναι δύο ειδών. Υποβοηθούμενη από το λογισμικό
|
||||
ή από το υλικό. Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση ολόκληρου του
|
||||
υλικού μέσω του υπερ-επόπτη που εκτελείται στο ΛΣ ενώ στο δεύτερο όπου δεν
|
||||
υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του εικονικού διακομιστή να κάνει
|
||||
χρήση της φυσικής κεντρικής μονάδας επεξεργασίας του διακομιστή φιλοξενίας εάν
|
||||
αυτή το υποστηρίζει \footfullcite{geeksforgeeksHardwareAssistedVirtualization}.
|
||||
Στην περίπτωση της παρα-εικονικοποίησης το λειτουργικό σύστημα αναγνωρίζει την
|
||||
ύπαρξη του υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο ώστε να μπορούν
|
||||
να επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό μειώνει την
|
||||
συμβατότητα σε σχέση με την πλήρη εικονικοποίηση, η άμεση επικοινωνία του
|
||||
λειτουργικού συστήματος με τον υπερ-επόπτη συμβάλει στην αύξηση της
|
||||
αποδοτικότητας.
|
||||
|
||||
\section{\textlatin{Docker In Cloud Computing}} \label{dockerInCloudComputing}
|
||||
\section{Εισαγωγή στα δοχεία και τον τρόπο λειτουργίας τους} \label{containerTechnologies}
|
||||
|
||||
Λόγω της αρχιτεκτονικής του είναι πολύ σύνηθες η θέση σε λειτουργία, εφαρμογών
|
||||
μέσω \textlatin{Docker} επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και
|
||||
εξαρτήσεις τους από το υπόλοιπο σύστημα και επιτρέπει την αποδοτικότερη
|
||||
διαχείριση τους μέσω ειδικών εντολών. Τα προβλήματα που μπορεί να προέκυπταν σε
|
||||
ένα περιβάλλον νέφους όπως μη συμβατές εκδόσεις προγραμμάτων και δυσκολία
|
||||
διαχείρισης τους τα λύνει δημιουργώντας έναν συστημικό τρόπο διανομής και
|
||||
ελέγχου εφαρμογών. Καθιστά επίσης και πολύ εύκολη τη μεταφορά τους σε
|
||||
οποιοδήποτε μηχάνημα.
|
||||
Τα δοχεία αποτελούν και αυτά κομμάτι των τεχνολογιών εικονικοποίησης αλλά σε
|
||||
επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
|
||||
δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
|
||||
(containerization). Σε αντίθεση με τις τεχνολογίες εικονικοποίησης που
|
||||
αναφέρθηκαν στο \ref{virtualizationTechnologiesIntroduction}, για την
|
||||
δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
|
||||
παίρνει η μηχανή δοχείων. Επιπλέον, ενώ οι εικονικές μηχανές καταλήγουν να
|
||||
περιέχουν εικονικό αντίγραφο του υλικού, δικό τους λειτουργικό σύστημα και
|
||||
εγκατεστημένα πακέτα προς υποστήριξη ενός λογισμικού, τα δοχεία αποτελούνται
|
||||
μονάχα από το λογισμικό προς εκτέλεση και τις εξαρτήσεις που χρειάζεται
|
||||
προκειμένου να είναι λειτουργικό.
|
||||
|
||||
\section{\textlatin{Docker Security}} \label{dockerSecurity}
|
||||
\clearpage
|
||||
|
||||
Μία από τις πιο σημαντικές προκλήσεις κατά την εκτέλεση υπηρεσιών σε δημόσια
|
||||
εικονικά περιβάλλοντα είναι η διατήρηση και επίτευξη της ασφάλειας. Παραδοσιακά
|
||||
κατά την επιλογή χρήσης τεχνολογιών εικονικοποίησης ανάμεσα στις επιλογές
|
||||
\textlatin{hypervisor-based} και \textlatin{container-based} είθισται να είναι
|
||||
προτιμότερη η δεύτερη. Μια λογική απόφαση εάν αναλογιστεί κανείς τα
|
||||
πλεονεκτήματα που προσφέρει στην απόδοση και την αποδοτική αλλά και εύκολη
|
||||
διαχείριση των υπηρεσιών όταν διατίθενται σε μορφή δοχείων. Παρ' όλα αυτά, για
|
||||
τον ίδιο λόγο που την καθιστά καταλληλότερη είναι και λιγότερο ασφαλής. Η
|
||||
στρώση απομόνωσης ανάμεσα στα προγράμματα και το μηχάνημα στο οποίο εκτελούνται
|
||||
αποτελεί ένα παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας επιτιθέμενος για
|
||||
να προκαλέσει ζημιές στο σύστημα, αφού θα πρέπει πρώτα να περάσει από τον
|
||||
εικονικό πυρήνα και μετά από τον \textlatin{hypervisor} έναντι στην
|
||||
αρχιτεκτονική δοχείων όπου υπάρχει άμεση επικοινωνία με τον πυρήνα του
|
||||
Τα απαραίτητα συστατικά για την επίτευξη της δοχειοποίησης είναι μια εικόνα
|
||||
δοχείου και μια μηχανή δοχείων. Στην εικόνα δοχείου εμπεριέχονται τα συστατικά
|
||||
μέρη ενός λογισμικού και οδηγίες συναρμολόγησης του προς ανάγνωση από την
|
||||
μηχανή δοχείων. Από εκεί και πέρα, για την δημιουργία δοχείων υπάρχει μια
|
||||
αλληλουχία βημάτων που πρέπει να έρθει εις πέρας. Αρχικά, η μηχανή δοχείων θα
|
||||
προσπελάσει την εικόνα δοχείου προκειμένου να εξακριβώσει τις προδιαγραφές του.
|
||||
Έπειτα, με την βοήθεια των μεθόδων απομόνωσης που έχει στην διάθεση της μέσω
|
||||
των μηχανισμών εικονικοποίησης του πυρήνα του λειτουργικού συστήματος
|
||||
φιλοξενίας, θα δημιουργήσει ένα εικονικό περιβάλλον απομονωμένο από το φυσικό
|
||||
ήδη υπάρχον και τέλος, θα πραγματοποιήσει εκκίνηση του δοχείου ως διεργασία του
|
||||
συστήματος.
|
||||
|
||||
\pagebreak
|
||||
Ορισμένα από αυτά τα βήματα περιλαμβάνουν και άλλες διαδικασίες για τις οποίες
|
||||
είναι υπεύθυνα συγκεκριμένα προγράμματα με τα οποία συνεργάζεται η μηχανή
|
||||
δοχείων. Υπάρχουν και μηχανές δοχείων χαμηλού επιπέδου έναντι των πιο γνωστών
|
||||
υψηλού επιπέδου όπως το Docker, στις οποίες λείπουν λειτουργίες όπως η απόκτηση
|
||||
εικόνων δοχείων από ένα κεντρικό αποθετήριο και ο έλεγχος εγκυρότητας των
|
||||
ρυθμίσεων των εικόνων αυτών. Οι μηχανές δοχείων υψηλού επιπέδου είναι
|
||||
ουσιαστικά μια συλλογή εργαλείων που διευκολύνουν την δοχειοποίηση
|
||||
απαλλάσσοντας τον χρήστη από την ανάγκη της χειροκίνητης εκτέλεσης των βημάτων
|
||||
της \footfullcite{sysdigContainerRuntime}.
|
||||
|
||||
\subsection{\textlatin{Docker Security Advantages}} \label{dockerSecurityAdvatnages}
|
||||
Το τελικό επιθυμητό αποτέλεσμα είναι η δημιουργία ενός απομονωμένου
|
||||
περιβάλλοντος στο οποίο πραγματοποιείται η εκτέλεση ενός λογισμικού με
|
||||
βιβλιοθήκες και εξαρτήσεις διαφορετικών εκδόσεων συγκριτικά με αυτές που μπορεί
|
||||
να προϋπάρχουν στο σύστημα. Το περιβάλλον αυτό είναι υποχρεωμένο να
|
||||
χρησιμοποιήσει ένα υποσύνολο των πόρων του συστήματος που του απονεμήθηκε μέσω
|
||||
της μηχανής δοχείων. Τα παραπάνω είναι εφικτά και με την χρήση εικονικών
|
||||
μηχανών αλλά με κόστος την επιβάρυνση του συστήματος φιλοξενίας λόγω της
|
||||
αδυναμίας διαμοιρασμού των πόρων με τον τρόπο που το επιτυγχάνουν τα δοχεία.
|
||||
Κάθε δοχείο μοιράζεται τον πυρήνα του λειτουργικού συστήματος φιλοξενίας με τα
|
||||
υπόλοιπα και κάθε στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα
|
||||
στιγμιότυπο λογισμικού, δύναται να χρησιμοποιηθεί ταυτοχρόνως από περισσότερα
|
||||
του ενός δοχεία προς αποφυγή διπλής αποθήκευσης
|
||||
\footfullcite{codemotionContainerImages}. Επιπλέον, κάθε εικόνα δοχείου δύναται
|
||||
να χρησιμοποιηθεί ως πρότυπο για την δημιουργία μιας καινούριας, καθιστώντας
|
||||
έτσι ευκολότερη την επεκτασιμότητα ενός λογισμικού σε αντίθεση με τις εικονικές
|
||||
μηχανές όπου κάθε νέο στιγμιότυπο τους απαιτεί την επαναληπτική εκτέλεση των
|
||||
βημάτων δημιουργίας τους.
|
||||
|
||||
Με τη χρήση της αρχιτεκτονικής δοχείων και ειδικότερα του \textlatin{Docker},
|
||||
έρχονται αρκετά εγγενή οφέλη ασφαλείας \cite{dockerInherentSecurity}. Ένα
|
||||
βασικό όφελος αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν
|
||||
την ακριβή κατανόηση του κώδικα που εκτελείται μέσα σε αυτά σε αντίθεση με μια
|
||||
εικονική μηχανή. Επιπρόσθετα, κατά την εμφάνιση προβλημάτων σε μία υπηρεσία με
|
||||
αρχιτεκτονική \textlatin{microservices} που κάνει χρήση δοχείων, είναι διακριτή
|
||||
η διευκόλυνση στον εντοπισμό της πηγής τους. Ένα εξίσου σημαντικό όφελος
|
||||
αποτελεί η μικρότερη επιφάνεια επίθεσης. Σε ένα παραδοσιακό περιβάλλον
|
||||
εκτέλεσης όπου γίνεται χρήση εικονικών διακομιστών, πρέπει να προστατευτούν τα
|
||||
μηχανήματα, ο διακομιστής και η υπηρεσία η ίδια, ενώ σε περιβάλλον δοχείων τα
|
||||
μέρη που χρήζουν προστασίας είναι ο διακομιστής, η υπηρεσία και η μηχανή
|
||||
δοχείων η οποία ασφαλίζεται ευκολότερα από μια εικονική μηχανή. Τέλος, δύο
|
||||
ακόμα υψίστης σημασίας πλεονεκτήματα είναι η ευκολία εφαρμογής ενημερώσεων
|
||||
ασφαλείας και η σταθερότητα του περιβάλλοντος. Η ενημέρωση ενός δοχείου είναι
|
||||
μια διαδικασία δύο μόνο εντολών ενώ η ευχέρεια της άγνοιας των μεταβλητών
|
||||
κομματιών του κάθε δοχείου καθιστά δυνατή την ασφάλιση της υπηρεσίας με τις
|
||||
συγκεκριμένες εξαρτήσεις που χρειάζεται ανεξαρτήτως των εκδόσεων που μπορεί να
|
||||
βρίσκονται ήδη στο σύστημα.
|
||||
\subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}
|
||||
|
||||
\subsection{\textlatin{Docker Security Disadvantages}} \label{dockerSecurityDisadvantages}
|
||||
Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux
|
||||
διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
|
||||
(λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
|
||||
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών και
|
||||
οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την δυνατότητα
|
||||
περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα αρχείων. Με την
|
||||
βοήθεια των εργαλείων που έχουν στην διάθεση τους, δύναται να πραγματοποιηθεί
|
||||
εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος εικονικοποίησης διακομιστών όπου ο
|
||||
πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη πολλαπλών απομονωμένων περιβαλλόντων
|
||||
\footfullcite{teimouriOsVirtualizationDefinition}, τα οποία συμπεριφέρονται ως
|
||||
ξεχωριστοί διακομιστές \footfullcite{webopediaOsVirtualizationDefinition}.
|
||||
|
||||
Παρ'' όλα τα πλεονεκτήματα του όπως η δυνατότητα απαλλαγής από εξαρτήσεις του
|
||||
εκάστοτε συστήματος και η ευελιξία διαχείρισης των δοχείων του, υπόκειται σε
|
||||
αρκετές ατασθαλίες. Οι πιο αξιοσημείωτες αυτών είναι η ανάγκη του να τρέχει υπό
|
||||
την κυριότητα του \textlatin{root} και η αρχικά ελαστικότερη απ'' ό,τι
|
||||
χρειάζεται απομόνωση του από τον πυρήνα του συστήματος. Με τα παραπάνω
|
||||
δεδομένα, μετά από μία επιτυχημένη επίθεση τύπου \textlatin{Container Escape},
|
||||
ο επιτιθέμενος έχει δικαιώματα \textlatin{root} και το σύστημα βρίσκεται υπό το
|
||||
έλεος του.
|
||||
Μια από τις υποχρεώσεις της μηχανής δοχείων είναι η επικοινωνία με τον πυρήνα
|
||||
του λειτουργικού συστήματος φιλοξενίας για να επιτευχθεί αυτή η εικονικοποίηση.
|
||||
Πρόκειται για μια διαδικασία κατά την οποία ένα λειτουργικό σύστημα επιτρέπει
|
||||
την απομόνωση των διεργασιών που εκτελούνται σε χώρους ονομάτων και την ανάθεση
|
||||
αποκλειστικών πόρων συστήματος σε αυτές. Με αυτό τον τρόπο, οι διεργασίες είναι
|
||||
ανεξάρτητες μεταξύ τους και απομονωμένες ενώ διαμοιράζονται με ασφαλή τρόπο (σε
|
||||
ένα βαθμό) τους πόρους του συστήματος. Ένα δοχείο μπορεί να θεωρηθεί πως
|
||||
αντιστοιχεί σε μια τέτοια απομονωμένη διεργασία.
|
||||
|
||||
\subsection{\textlatin{Overcoming Docker's security disadvantages}} \label{overcomingDockerDisadvantages}
|
||||
\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
|
||||
|
||||
Ενώ μια εικονική μηχανή είναι μια πλήρης αναπαράσταση ενός φυσικού διακομιστή,
|
||||
ένα δοχείο εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Αυτό
|
||||
σημαίνει πως εάν θεωρηθεί ως τελικός στόχος η εκτέλεση ενός λογισμικού
|
||||
απομονωμένο από το υπόλοιπο σύστημα, αυτό επιτυγχάνεται με δύο διαφορετικούς
|
||||
τρόπους αφού οι εικονικές μηχανές και τα δοχεία χρησιμοποιούν διαφορετικού
|
||||
είδους εικονικοποίηση. Στην περίπτωση των δοχείων δεν έχουμε απομόνωση μηχανών
|
||||
αλλά διεργασιών. Γεγονός που συμβάλει στην αποφυγή της επιβάρυνσης του
|
||||
συστήματος που θα επιβάλλονταν από τις διεργασίες του υπερ-επόπτη και της
|
||||
καθυστέρησης που θα υπήρχε για την εκκίνηση ενός ολόκληρου λειτουργικού
|
||||
συστήματος. Επιπλέον, η μη χρήση τεχνολογιών εικονικοποίησης σε επίπεδο υλικού
|
||||
αυξάνει την μεταφερσιμότητα των δοχείων αφού σε μια εικόνα δοχείου μπορούν να
|
||||
ορισθούν όλες οι απαραίτητες εξαρτήσεις ενός λογισμικού και να αναδημιουργηθούν
|
||||
σε οποιοδήποτε περιβάλλον νέφους.
|
||||
|
||||
Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
|
||||
αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
|
||||
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μια επιχείρησης είτε
|
||||
σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
|
||||
εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
|
||||
λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
|
||||
εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
|
||||
την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
|
||||
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
|
||||
βιβλιοθήκες και τις εξαρτήσεις της \footfullcite{ibmContainerVsVm}.
|
||||
|
||||
Η εικόνα \ref{fig:containerVsVm} παρουσιάζει τη διαφορά των δύο αρχιτεκτονικών
|
||||
|
||||
\begin{center}
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||||
\captionof{figure}{Εικονικοποίηση έναντι δοχείων \cite{redhatVirtualizationDefinition}}
|
||||
\label{fig:containerVsVm}
|
||||
\end{figure}
|
||||
\vspace*{-30pt}
|
||||
\end{center}
|
||||
|
||||
\clearpage
|
||||
|
||||
Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
|
||||
γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
|
||||
σύμφωνα με τη Red Hat \footfullcite{redhatContainerVsVm}, το μέγεθος των
|
||||
εικονικών μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της
|
||||
τάξεως megabyte. Πολλές φορές, όπως αναφέρεται και στο \cite{ibmContainerVsVm}
|
||||
\footfullcite{ibmContainerVsVm}, τα δοχεία χρησιμοποιούνται για εφαρμογές
|
||||
αρχιτεκτονικής μικρο-υπηρεσιών (microservices), όπου κάθε ξεχωριστό κομμάτι
|
||||
(δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό της εφαρμογής που παίρνει
|
||||
την μορφή δοχείου. Με αυτόν τον τρόπο, είναι ευκολότερη η κλιμάκωση μιας
|
||||
εφαρμογής απ' ότι θα ήταν με μια μονολιθική αρχιτεκτονική. Αυτό συμβαίνει διότι
|
||||
μπορεί να κλιμακώνεται μόνο το μέρος ή τα μέρη της που έχουν αύξηση του φόρτου
|
||||
εργασίας τους, μέσω της χρήσης περισσότερων δοχείων που αντιστοιχούν σε αυτά τα
|
||||
μέρη/μικρο-υπηρεσίες. Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα
|
||||
απαιτούσε την δημιουργία πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών
|
||||
εικονικών μηχανών, οδηγώντας σε μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του
|
||||
γεγονότος πως μια εφαρμογή αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες
|
||||
μπορεί να έχουν πολλαπλά στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα
|
||||
χρονική στιγμή, απαιτείται η χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για
|
||||
την αυτοματοποίηση της εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής
|
||||
κατά μήκος πολλαπλών πόρων (δηλ. εικονικών ή φυσική μηχανών) όπως είναι το
|
||||
Kubernetes ή το Docker Swarm.
|
||||
|
||||
Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
|
||||
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
|
||||
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
|
||||
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
|
||||
το ίδιο ισχύει και αντιστρόφως \footfullcite{containerOSlimitations}.
|
||||
|
||||
Εν γένει τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
|
||||
μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
|
||||
και η μεταφερσιμότητα τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
|
||||
αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
|
||||
σκοπό την στέγαση ενός ολόκληρου ξεχωριστού λειτουργικού συστήματος (όπως
|
||||
γίνεται στις εικονικές μηχανές). Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε
|
||||
οποιοδήποτε περιβάλλον είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως το
|
||||
Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
|
||||
σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
|
||||
μη λειτουργικών απαιτήσεων τους.
|
||||
|
||||
\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}
|
||||
|
||||
Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει του όρους Docker και
|
||||
Container (δοχείο) αν και είναι διαφορετικοί. Παρόλα αυτά η ιδέα της
|
||||
δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
|
||||
το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
|
||||
είσοδο τους από το 1979, όταν εισήχθη το chroot \footfullcite{chrootCommand}
|
||||
στην έβδομη έκδοση του Unix \footfullcite{containerHistory}. Πρόκειται για μια
|
||||
εντολή που περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα
|
||||
συγκεκριμένο φάκελο ο οποίος ορίζεται ως ο καινούριος διαχειριστικός (root). Ο
|
||||
κύριος σκοπός του chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην
|
||||
περίπτωση εκμετάλλευσης μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν
|
||||
ανεπηρέαστα τα μέρη του συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση.
|
||||
Εκείνη την εποχή αυτό ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό
|
||||
αυξάνονταν και υπήρχε η ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από
|
||||
κατασκευής του, το chroot δεν περιόριζε έναν χρήστη ή μια διεργασία με
|
||||
διαχειριστικά δικαιώματα \footfullcite{chrootRestrictions}. Μερικά χρόνια
|
||||
αργότερα, το 2004 δημιουργήθηκαν και ενσωματώθηκαν στον πυρήνα του Linux οι
|
||||
ομάδες ελέγχου με την βοήθεια των οποίων ήταν πλέον δυνατή η απομόνωση πόρων
|
||||
του συστήματος σε ένα υποσύνολο διεργασιών.
|
||||
|
||||
\clearpage
|
||||
|
||||
Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
|
||||
2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
|
||||
Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
|
||||
εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
|
||||
Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα επέτρεπε πλήρη
|
||||
εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε αρκετές
|
||||
λειτουργίες όπως η δημιουργία, η εκκίνηση και ο καθαρισμός LXC δοχείων. Παρόλα
|
||||
αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
|
||||
εφαρμογών \footfullcite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την
|
||||
χρήση του όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||||
|
||||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων τα οποία χρησιμοποιούνται
|
||||
ακόμα και στις μέρες μας, λόγω ενός συνδυασμού της δυσκολίας στην χρήση τους
|
||||
και του εξειδικευμένου σκοπού ύπαρξης τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
|
||||
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
|
||||
οι τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker αποτελεί μια υπηρεσία PaaS η
|
||||
οποία παρέχει μια πλατφόρμα με μηχανισμούς για συναρμολόγηση, θέση σε
|
||||
λειτουργία, εκτέλεση, ενημέρωση και διαχείριση προγραμμάτων σε μορφή δοχείων.
|
||||
Σε αντίθεση με το LXC, αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο
|
||||
στόχο την δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο
|
||||
κώδικα, τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
|
||||
(φιλοξενίας) παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων δοχείωv
|
||||
όπως είναι το Docker Hub \footfullcite{dockerhub}, το επίσημο αποθετήριο του
|
||||
Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή
|
||||
οποιοδήποτε άλλο αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI
|
||||
(Open Container Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι
|
||||
χρήστες έχουν πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους
|
||||
επιτρέπουν να ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής.
|
||||
Επιπλέον, όντας μια μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα
|
||||
απαιτούσαν εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν
|
||||
συμπυκνωθεί σε απλές εντολές καθιστώντας έτσι εύκολη την χρήση του για
|
||||
προγραμματιστές κάθε επιπέδου και απλοποιώντας κατά πολύ την διαδικασία
|
||||
ανάπτυξης και παράδοσης κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς
|
||||
τον χρήστη διεπαφή, έλεγχο εκδόσεων (version control) για δοχεία
|
||||
\footfullcite{LXCvsDocker2} και ένα οικοσύστημα γύρω από όλα αυτά, είναι
|
||||
εμφανής ο λόγος που κατάφερε να επισκιάσει το LXC.
|
||||
|
||||
\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
|
||||
|
||||
Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
|
||||
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους όπως το μοντέλο καταρράκτη
|
||||
(waterfall) \footfullcite{waterfall} με βάση του οποίου υπήρχε ένα συγκεκριμένο
|
||||
αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
|
||||
έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
|
||||
αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
|
||||
στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
|
||||
\footfullcite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
|
||||
πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
|
||||
προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
|
||||
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \footfullcite{devops}
|
||||
όπου οι ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής
|
||||
επικοινωνούν στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης
|
||||
λογισμικού. Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD
|
||||
(Continuous Integration/Continuous Delivery) \footfullcite{cicd}. Κατά το
|
||||
μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες που εκτελούνται κατά
|
||||
την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής προκειμένου να
|
||||
πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να εντοπίζονται σφάλματα και
|
||||
να παράγονται εκτελέσιμα πακέτα.
|
||||
|
||||
Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
|
||||
και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
|
||||
εφαρμογών και την εκτέλεση τους σε οποιοδήποτε περιβάλλον. Λόγω των
|
||||
χαρακτηριστικών τους, εξαλείφουν τυχόν προβλήματα συμβατότητας μεταξύ των
|
||||
περιβαλλόντων εκτέλεσης τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων αφού
|
||||
μπορεί κανείς να εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για
|
||||
συγκεκριμένη ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
|
||||
χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους, κάτι που μειώνει
|
||||
ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα. Επιπλέον, λόγω
|
||||
της ταχείας διάθεσης και εκτέλεσης τους, συμβαδίζουν πλήρως με τον ρυθμό
|
||||
ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
|
||||
|
||||
\clearpage
|
||||
|
||||
Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
|
||||
προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
|
||||
αρχιτεκτονική μικρο-υπηρεσιών. Σε αυτήν την περίπτωση, η εφαρμογή αποτελείται
|
||||
από πολλά δοχεία όπου το κάθε ένα από αυτά είναι υπεύθυνο για μια συγκεκριμένη
|
||||
λειτουργία της (μικρο-υπηρεσία). Τα δοχεία αυτά είναι ανεξάρτητα μεταξύ τους
|
||||
και κατά την ανάγκη κλιμάκωσης μιας συγκεκριμένης λειτουργίας της εφαρμογής
|
||||
αυτό μπορεί να επιτευχθεί δίχως την περιττή κλιμάκωση όλων των υπολοίπων.
|
||||
Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ τους καθιστά πιο σταθερή την
|
||||
εφαρμογή αφού σε περίπτωση που κάποιο από αυτά αποτύχει, η υπόλοιπη εφαρμογή θα
|
||||
συνεχίσει να λειτουργεί κανονικά και η ανακατασκευή του δοχείου που απέτυχε
|
||||
μπορεί να επιτευχθεί εύκολα και γρήγορα με μια απλή τροποποίηση της εκάστοτε
|
||||
εικόνας δοχείου.
|
||||
|
||||
\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
|
||||
|
||||
Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
|
||||
τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
|
||||
υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
|
||||
συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
|
||||
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι, η
|
||||
εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
|
||||
πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
|
||||
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS (Container as a Service) όπως η
|
||||
ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
\footfullcite{caas} των υπηρεσιών IaaS (Infrastructure as a Service) όπου ένας
|
||||
πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
|
||||
σκοπού, παρέχει μια ευέλικτη υποδομή έτοιμη για την εκτέλεση δοχείων
|
||||
\footfullcite{caasVsIaas}.
|
||||
|
||||
\clearpage
|
||||
|
||||
Από τις δύο αυτές επιλογές, η πιο δημοφιλής είναι η πρώτη καθώς προσφέρει μια
|
||||
ευελιξία ως προς την διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι
|
||||
χρήστες έχουν την δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές
|
||||
ασφαλείας που μπορεί να έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν
|
||||
επιπλέον λογισμικό παρακολούθησης και ελέγχου ποιότητας των δοχείων και να
|
||||
προσαρμόσουν το περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η
|
||||
ύπαρξη μιας επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου
|
||||
συστήματος αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο
|
||||
βρεθεί σε κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την
|
||||
περιορισμένη έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη
|
||||
την ανίχνευση και απομόνωση των προβλημάτων ασφαλείας όπως επίσης και την
|
||||
αποκατάσταση τους.
|
||||
|
||||
Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
|
||||
επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
|
||||
διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
|
||||
περιπτώσεις που οι χρήστες δεν έχουν την απαραίτητη εμπειρία σε αυτόν τον τομέα
|
||||
ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
|
||||
υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
|
||||
υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
|
||||
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων όπως η ταχεία διάθεση και
|
||||
απόσυρση τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση. Συγκεκριμένα,
|
||||
μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες ενορχήστρωσης δοχείων
|
||||
\footfullcite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου στησίματος πλατφορμών
|
||||
όπως το Kubernetes \footfullcite{kubernetes} και το Docker Swarm
|
||||
\footfullcite{dockerSwarm}.
|
||||
|
||||
\clearpage
|
||||
|
||||
Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
|
||||
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
|
||||
επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
|
||||
σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
|
||||
διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
|
||||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον ανάπτυξης
|
||||
όπως μη συμβατές εκδόσεις προγραμμάτων και δυσκολία διαχείρισης τους
|
||||
εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει έναν
|
||||
συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||||
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
|
||||
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
|
||||
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
|
||||
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών, δηλαδή να
|
||||
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
|
||||
εφαρμογής \footfullcite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς
|
||||
παρόχους με βάση τις ανάγκες τους.
|
||||
|
||||
\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
|
||||
|
||||
Μία από τις πιο σημαντικές προκλήσεις των επιχειρήσεων κατά την διάθεση
|
||||
υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά κατά την
|
||||
επιλογή χρήσης τεχνολογιών εικονικοποίησης, ανάμεσα στις επιλογές
|
||||
εικονικοποίησης υλικού και εικονικοποίησης ΛΣ είθισται να προτιμάται η δεύτερη.
|
||||
Μια λογική απόφαση εάν αναλογιστεί κανείς τα πλεονεκτήματα που προσφέρει τόσο
|
||||
στην απόδοση πόρων του συστήματος όσο και στην αποδοτική αλλά και εύκολη
|
||||
διαχείριση των υπηρεσιών όταν αυτές διατίθενται σε μορφή δοχείων. Παρ' όλα
|
||||
αυτά, η επιλογή αυτή είναι και λιγότερο ασφαλής στην περίπτωση που αφεθεί στις
|
||||
αρχικές ρυθμίσεις.
|
||||
|
||||
\clearpage
|
||||
|
||||
Για τον λόγο αυτό, εάν η μέγιστη δυνατή απόδοση δεν είναι μια από τις κύριες
|
||||
προτεραιότητες της επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
|
||||
συστήματος διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
|
||||
μεταφερσιμότητα και την απαλλαγή από τις εξαρτήσεις του εκάστοτε προγράμματος
|
||||
ακόμα και χωρίς την περαιτέρω διαμόρφωση των ρυθμίσεων του, η προτεινόμενη
|
||||
χρήση είναι η εκτέλεση του μέσω μιας εικονικής μηχανής. Η στρώση απομόνωσης
|
||||
μέσω της εικονικοποίησης υλικού ανάμεσα στα προγράμματα και το μηχάνημα στο
|
||||
οποίο εκτελούνται αποτελεί ένα παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας
|
||||
επιτιθέμενος για να προκαλέσει ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα
|
||||
να περάσει από τον εικονικό πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, η
|
||||
ο συνδυασμός με την αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο
|
||||
απομόνωσης εφόσον στην προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα
|
||||
του συστήματος αφορά το ΛΣ φιλοξενίας και όχι το κύριο σύστημα.
|
||||
|
||||
Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
|
||||
να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
|
||||
τροποποίηση των ρυθμίσεων και του τρόπου λειτουργίας του Docker ώστε να
|
||||
μπορέσει να επιτευχθεί μια ικανοποιητική ισορροπία μεταξύ της ασφάλειας και της
|
||||
απόδοσης του συστήματος. Με βάση μια έρευνα που πραγματοποιήθηκε από την IBM
|
||||
σχετικά με την ασφάλεια των δοχείων \footfullcite{containerSecurity}, βρέθηκε
|
||||
πως ένα ορθώς ασφαλισμένο δοχείο μπορεί να παρέχει το ίδιο επίπεδο ασφάλειας με
|
||||
μια εικονική μηχανή ή ακόμα και μεγαλύτερο. Συγκεκριμένα, στην έρευνα αυτή
|
||||
αναφέρεται πως προκειμένου να ποσοτικοποιηθεί η ασφάλεια των δοχείων θα πρέπει
|
||||
να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
|
||||
χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
|
||||
ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
|
||||
αντιστοιχεί. Σε αυτήν την περίπτωση εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
|
||||
τότε είναι υπεύθυνος για περίπου το ίδιο ποσοστό υποδομών με τον πάροχο και
|
||||
επωφελείται άμεσα από τις προσπάθειες ασφάλισης του παρόχου για το ποσοστό του.
|
||||
Επομένως, συμπεραίνεται πως από την οπτική γωνία του τελικού χρήστη είναι πιο
|
||||
ασφαλές να χρησιμοποιήσει τεχνολογίες εικονικοποίησης ΛΣ μέσω ενός παρόχου
|
||||
νέφους για την παροχή των υπηρεσιών του
|
||||
\footfullcite{containerSecurityExplained}.
|
||||
|
||||
\subsection{Πλεονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityAdvatnages}
|
||||
|
||||
Με τη χρήση της αρχιτεκτονικής δοχείων και ειδικότερα του Docker, έρχονται
|
||||
αρκετά εγγενή οφέλη ασφαλείας \footfullcite{dockerInherentSecurity}. Ένα βασικό
|
||||
όφελος αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν την
|
||||
ακριβή κατανόηση του κώδικα που εκτελείται μέσα σε αυτά σε αντίθεση με την
|
||||
περίπτωση χρήσης αποκλειστικά εικονικών μηχανών. Επιπρόσθετα, κατά την εμφάνιση
|
||||
προβλημάτων σε μία υπηρεσία με αρχιτεκτονική μικρο-υπηρεσιών που κάνει χρήση
|
||||
δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.
|
||||
|
||||
Ένα εξίσου σημαντικό όφελος αποτελεί το επιπρόσθετο επίπεδο ασφάλειας που
|
||||
παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρυνθεί το ΛΣ
|
||||
φιλοξενίας (αν υπάρχει), ο υπερ-επόπτης, το φιλοξενούμενο ΛΣ και η εκτελούμενη
|
||||
υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρυνθεί το ΛΣ που φιλοξενεί τη
|
||||
μηχανή δοχείων, η μηχανή δοχείων και η υπηρεσία. Πράγμα που σημαίνει πως σε ένα
|
||||
εικονικό περιβάλλον με την χρήση του Docker έχουμε επιπρόσθετα επίπεδα που
|
||||
χρειάζονται σκλήρυνση. Συνεπώς, σε εικονικά περιβάλλοντα, η χρήση δοχείων
|
||||
έρχεται με την σκλήρυνση ενός επιπλέον συστατικού, της μηχανής δοχείων, οπότε
|
||||
προσφέρει καλύτερο επίπεδο ασφάλειας.
|
||||
|
||||
Δύο ακόμα σημαντικά πλεονεκτήματα είναι η ευκολία εφαρμογής ενημερώσεων
|
||||
ασφαλείας στα δοχεία και η σταθερότητα του περιβάλλοντος που προσφέρεται μέσω
|
||||
αυτών στις εφαρμογές. Ειδικότερα, η ενημέρωση ενός δοχείου είναι μια διαδικασία
|
||||
δύο μόνο εντολών, ενώ το προσφερόμενο περιβάλλον είναι σταθερό με την λογική
|
||||
πως η μηχανή δοχείου παρέχει ένα επίπεδο πάνω από το ΛΣ, κι επομένως το
|
||||
περιβάλλον αυτό δεν είναι ξεχωριστά ευμετάβλητο από την εκάστοτε εφαρμογή που
|
||||
εκτελείται μέσα σε αυτό. Άρα, δεν κινδυνεύει από νέα προβλήματα ασφαλείας που
|
||||
θα μπορούσαν να επιφέρουν τυχόν ενημερώσεις των εξαρτήσεων της εφαρμογής χωρίς
|
||||
την ταυτόχρονη ενημέρωση της εφαρμογής της ίδιας.
|
||||
|
||||
\clearpage
|
||||
|
||||
\subsection{Μειονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityDisadvantages}
|
||||
|
||||
Παρ' όλα τα προαναφερόμενα πλεονεκτήματα του Docker όπως η δυνατότητα απαλλαγής
|
||||
από εξαρτήσεις του εκάστοτε συστήματος και η ευελιξία διαχείρισης των δοχείων
|
||||
του, αυτό υπόκειται σε αρκετές ατασθαλίες σε σχέση με την ασφάλεια. Οι πιο
|
||||
αξιοσημείωτες από αυτές είναι η ανάγκη εκτέλεσης του Docker με διαχειριστικά
|
||||
δικαιώματα και η αρχικά ελαστικότερη απ' ό,τι χρειάζεται απομόνωση του από τον
|
||||
πυρήνα του συστήματος. Ο άμεσος αντίκτυπος των παραπάνω είναι πως τα δοχεία
|
||||
είναι πιο ευάλωτα από άλλες τεχνολογίες σε επιθέσεις τύπου άρνησης υπηρεσιών
|
||||
και σε επιθέσεις που εκμεταλλεύονται ευπάθειες του πυρήνα με σκοπό να ξεφύγουν
|
||||
από το δοχείο και να αποκτήσουν πρόσβαση στο κύριο σύστημα (Container Escape
|
||||
\footfullcite{containerEscapeTechniques}).
|
||||
|
||||
Το γεγονός που αυξάνει τον κίνδυνο κατά την διάρκεια μιας επίθεσης τύπου
|
||||
άρνησης υπηρεσιών είναι πως σε αντίθεση με μια εικονική μηχανή όπου επιλέγεται
|
||||
το εύρος πρόσβασης στους πόρους του συστήματος κατά τη δημιουργία της, η αρχική
|
||||
ρύθμιση του Docker επιτρέπει στα δοχεία να χρησιμοποιήσουν το ίδιο ποσοστό
|
||||
πόρων με το κύριο σύστημα, δηλαδή χωρίς περιορισμούς. Επομένως, εάν ένα δοχείο
|
||||
βρεθεί υπό τον έλεγχο ενός επιτιθέμενου, αυτό μπορεί δυνητικά να εμποδίσει την
|
||||
εκτέλεση άλλων δοχείων ή ακόμα και την εκτέλεση άλλων εφαρμογών που εκτελούνται
|
||||
στο σύστημα.
|
||||
|
||||
Σχετικά με τις επιθέσεις που αποσκοπούν στην απόκτηση πρόσβασης στο κύριο
|
||||
σύστημα μέσω του δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
|
||||
δοχείων σε συνδυασμό με τις αρχικές ρυθμίσεις ασφαλείας του Docker. Λόγω της
|
||||
απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
|
||||
ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
|
||||
ένα δοχείο μπορεί να εκμεταλλευτεί μια ευπάθεια του πυρήνα προκειμένου να
|
||||
αποκτήσει πρόσβαση στο κύριο σύστημα και εφόσον η εκτέλεση του Docker γίνεται
|
||||
με διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape
|
||||
θα έχει διαχειριστικά δικαιώματα και ο επιτιθέμενος
|
||||
\footfullcite{containerEscapeRepercussions}.
|
||||
|
||||
\clearpage
|
||||
|
||||
\subsection{Ξεπερνώντας τα μειονεκτήματα ασφαλείας του Docker} \label{overcomingDockerDisadvantages}
|
||||
|
||||
Οι πιο συνήθεις τρόποι αντιμετώπισης της ανεπαρκούς προκαθορισμένης ασφάλειας
|
||||
του \textlatin{Docker} είναι η ρύθμιση καλύτερων \textlatin{Apparmor} προφίλ ή
|
||||
κανόνων \textlatin{SELinux} προκειμένου να απομονωθεί καλύτερα από το κύριο
|
||||
του Docker (δηλ. της ελαστικής απομόνωσης) είναι η ρύθμιση καλύτερων AppArmor
|
||||
προφίλ ή κανόνων SELinux προκειμένου να απομονωθεί καλύτερα από το κύριο
|
||||
σύστημα. Στην πραγματικότητα, αυτές οι πρακτικές λαμβάνουν υπόψιν τους κυρίως
|
||||
τα δοχεία και όχι τη μηχανή δοχείων καθ'' αυτού. Γι'' αυτό τον λόγο πολλές
|
||||
φορές πρέπει να ακολουθούνται και καλύτερες πρακτικές κατά τη λειτουργία του
|
||||
όπως η αποφυγή χρήσης του διαχειριστικού λογαριασμού όσον αφορά τα δοχεία και η
|
||||
αποφυγή λήψης δοχείων από μη έμπιστες πηγές.
|
||||
τα δοχεία και όχι τη μηχανή δοχείων καθ' αυτού. Γι' αυτό τον λόγο, πολλές φορές
|
||||
πρέπει να ακολουθούνται και καλύτερες πρακτικές κατά τη λειτουργία/χρήση του
|
||||
Docker, όπως η αποφυγή χρήσης του διαχειριστικού λογαριασμού (σε διεργασίες)
|
||||
όσον αφορά τα δοχεία και η αποφυγή λήψης δοχείων από μη έμπιστες πηγές. Υπάρχει
|
||||
επομένως ανάγκη δημιουργίας ενός εργαλείου που αυτοματοποιημένα μπορεί να
|
||||
δημιουργεί ασφαλή εικονικοποιημένα περιβάλλοντα, καθώς και να εγκαθιστά σε
|
||||
αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας του Docker και των δοχείων
|
||||
του, μια σκληρυμένη έκδοση του Docker.
|
||||
|
||||
\pagebreak
|
||||
Με τη χρήση του εργαλείου SecDep που θα περιγράψουμε παρακάτω στο κεφάλαιο
|
||||
\ref{installationANDShowcase}, θα επιτευχθεί η ασφάλιση του Docker και του
|
||||
συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές,
|
||||
χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας
|
||||
το Docker εξολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο
|
||||
αυτό επικοινωνεί με πολλούς παρόχους νέφους στέλνοντας τους παραμέτρους για τις
|
||||
προδιαγραφές εικονικών μηχανών προκειμένου να μπορέσουν να δημιουργηθούν με
|
||||
αυτοματοποιημένο τρόπο επιτρέποντας έτσι την δημιουργία πολλαπλών ασφαλών
|
||||
περιβαλλόντων ώστε να μπορεί ένας χρήστης να εγκαθιστά εκεί τα δοχεία της
|
||||
εφαρμογής του. Η σκλήρυνση του ΛΣ επιτυγχάνεται με την εκτέλεση πολλών βημάτων
|
||||
στα οποία μεταξύ άλλων περιλαμβάνεται η σκλήρυνση του SSH, ο εντοπισμός, η
|
||||
εγκατάσταση, η ρύθμιση και η ενεργοποίηση του κατάλληλου προγράμματος για
|
||||
ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access Control) και η
|
||||
δημιουργία και ενεργοποίηση περιοδικά εκτελέσιμων προγραμμάτων για την
|
||||
ενημέρωση του συστήματος και το άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η
|
||||
απεξάρτηση από τον διαχειριστικό λογαριασμό επιτυγχάνεται χάρη στη δουλειά του
|
||||
Akihiro Suda πάνω στο rootlesskit \footfullcite{AkihiroSuda}, επιτρέποντας έτσι
|
||||
έναν πλαστό διαχειριστικό λογαριασμό προκειμένου να μπορέσει η μηχανή δοχείων
|
||||
να εκτελεστεί υπό την κυριότητα οποιουδήποτε χρήστη του συστήματος. Τέλος, η
|
||||
αντικατάσταση του αρχικού Container Runtime με το αντίστοιχο του gVisor
|
||||
\footfullcite{gVisor}, εισάγει ένα πιο συμπαγές τοίχος προστασίας απέναντι σε
|
||||
συνηθισμένες επιθέσεις κατά των δοχείων, καθιστώντας το σύστημα μας πιο ασφαλές
|
||||
συγκριτικά με τις αρχικές/προκαθορισμένες ρυθμίσεις.
|
||||
|
||||
Με τη χρήση του εργαλείου \textlatin{SecDep} που θα περιγράψουμε παρακάτω
|
||||
[\ref{installationANDShowcase}], θα επιτευχθεί η ασφάλιση του
|
||||
\textlatin{Docker} και του συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας
|
||||
ορθές πρακτικές, χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό
|
||||
\textlatin{Container Runtime} και εκτελώντας το \textlatin{Docker} εξολοκλήρου
|
||||
χωρίς την ανάγκη του \textlatin{root}. Η απεξάρτηση από τον διαχειριστικό
|
||||
λογαριασμό επιτυγχάνεται χάρη στη δουλειά του \textlatin{Akihiro Suda} πάνω στο
|
||||
\textlatin{rootlesskit} \cite{AkihiroSuda} επιτρέποντας έτσι έναν πλαστό
|
||||
διαχειριστικό λογαριασμό προκειμένου να μπορέσει η μηχανή δοχείων να εκτελεστεί
|
||||
υπό την κυριότητα οποιουδήποτε χρήστη του συστήματος. Επιπροσθέτως, η
|
||||
αντικατάσταση του αρχικού \textlatin{Container Runtime} με το αντίστοιχο του
|
||||
\textlatin{gVisor} \cite{gVisor}, εισάγει ένα πιο συμπαγές τοίχος προστασίας
|
||||
απέναντι σε συνηθισμένες επιθέσεις κατά των δοχείων καθιστώντας το σύστημα μας
|
||||
πιο ασφαλές συγκριτικά με τις αρχικές ρυθμίσεις.
|
||||
\clearpage
|
||||
|
||||
\section{Δομή Εργασίας} \label{structure}
|
||||
|
||||
Συνεχίζοντας παρακάτω, η δομή που θα συναντήσει ο αναγνώστης είναι η εξής. Στο
|
||||
κεφάλαιο [\ref{background}] θα μελετήσουμε τον όρο \textlatin{cloud computing},
|
||||
θα αναλύσουμε τις διάφορες τεχνολογίες εικονικοποίησης και θα εμβαθύνουμε στην
|
||||
τεχνολογία των δοχείων και συγκεκριμένα στην ασφάλεια του \textlatin{Docker}.
|
||||
Στο επόμενο κεφάλαιο [\ref{relevantWork}], θα δούμε εργασίες σχετικές με την
|
||||
παρούσα και θα πραγματοποιηθεί ανάλυση και σύγκριση αυτών. Αμέσως μετά, στο
|
||||
[\ref{projectDevelopment}], αναφερόμαστε στον σχεδιασμό του εργαλείου μιλώντας
|
||||
για τις απαιτήσεις, τα συστατικά του μέρη και πως αυτά συνεργάζονται μεταξύ
|
||||
τους. Προχωρώντας στο [\ref{installationANDShowcase}], θα αναφερθούμε στις
|
||||
οδηγίες εγκατάστασης και λειτουργίας του εργαλείου με βάση στοχευμένα σενάρια
|
||||
χρήσης. Έπειτα, στο [\ref{experimentationANDresults}] βλέπουμε την
|
||||
αποδοτικότητα του μετά από αρκετές χρήσεις και μετρήσεις που έγιναν προκειμένου
|
||||
να αποτιμηθεί ορθότερα η εξασφάλιση των στόχων του. Τέλος, στο
|
||||
[\ref{conclusions}], γίνεται αναφορά σημείων που θα μπορούσαν να επωφεληθούν με
|
||||
βελτιώσεις προκειμένου να μπορέσει το εργαλείο αυτό να πάρει μια θέση στην
|
||||
αγορά.
|
||||
Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο κεφάλαιο \ref{background} θα
|
||||
μελετήσουμε τον όρο νεφο-υπολογιστική, θα αναλύσουμε τις διάφορες τεχνολογίες
|
||||
εικονικοποίησης και θα εμβαθύνουμε στην τεχνολογία των δοχείων και συγκεκριμένα
|
||||
στην ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το \ref{relevantWork}),
|
||||
θα δούμε εργασίες σχετικές με την παρούσα και θα πραγματοποιηθεί ανάλυση και
|
||||
σύγκριση αυτών με την προτεινόμενη εργασία της διπλωματικής. Αμέσως μετά, στο
|
||||
κεφάλαιο \ref{projectDevelopment}, αναφερόμαστε στην ανάπτυξη του προτεινόμενου
|
||||
εργαλείου και τα παράγωγά της (απαιτήσεις, σχεδιαστικά μοντέλα, κώδικα
|
||||
υλοποίησης κα.). Προχωρώντας στο κεφάλαιο \ref{installationANDShowcase}, θα
|
||||
αναφερθούμε στις οδηγίες εγκατάστασης και λειτουργίας του εργαλείου με βάση
|
||||
στοχευμένα σενάρια χρήσης. Έπειτα, στο κεφάλαιο \ref{experimentationANDresults}
|
||||
αποτιμάται η αποδοτικότητα του εργαλείου κατά την πραγματική χρήση του
|
||||
προκειμένου να εξετασθεί με πρακτικό τρόπο η ικανότητα εξασφάλισης των στόχων
|
||||
του. Τέλος, στο κεφάλαιο \ref{conclusions}, αναφέρονται δυνητικές επεκτάσεις
|
||||
και βελτιώσεις του προτεινόμενου εργαλείου προκειμένου αυτό να μπορέσει να
|
||||
πάρει μια θέση στην αγορά.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,8 +1,24 @@
|
||||
\chapter{Σχετικές Εργασίες} \label{relevantWork}
|
||||
|
||||
Με την πάροδο των χρόνων και τη ραγδαία αύξηση ενδιαφέροντος προς τον κλάδο της
|
||||
υπολογιστικής νέφους, άρχισε να γίνεται όλο και σημαντικότερη η ανάγκη
|
||||
προστασίας των υποδομών των επιχειρήσεων. Πλέον, οι περισσότερες υπηρεσίες που
|
||||
διατίθενται στους χρήστες κάνουν χρήση τεχνολογιών εικονικοποίησης ή/και
|
||||
δοχείων. Όμως όλες είναι εν δυνάμει ευάλωτες σε επιθέσεις εάν δε ληφθούν τα
|
||||
απαραίτητα μέτρα προστασίας και αφήσουν ανοιχτά σημεία εισόδου στο δίκτυο τους.
|
||||
υπολογιστικής νέφους, άρχισε να γίνεται όλο και πιο επιτακτική η ανάγκη για
|
||||
αυτοματοποιημένο στήσιμο και προστασία των υποδομών των επιχειρήσεων. Η χρήση
|
||||
τεχνολογιών εικονικοποίησης και η άνοδος υπηρεσιών IaaS, έχει ελαφρύνει τον
|
||||
φόρτο εργασίας όσον αφορά το στήσιμο των υποδομών αφού πλέον υπάρχουν πολλά
|
||||
εργαλεία στα οποία γίνεται καθορισμός τους. Η αυτοματοποίηση της ασφάλισης τους
|
||||
όμως είναι ακόμα σε πρώιμο στάδιο. Οι περισσότερες υπηρεσίες που διατίθενται
|
||||
στους χρήστες κάνουν χρήση τεχνολογιών εικονικοποίησης έμμεσα από τον πάροχο
|
||||
νέφους που χρησιμοποιούν και τεχνολογίες δοχείων άμεσα από επιλογή τους λόγω
|
||||
της υπεροχής που παρέχουν στη διαχείριση. Όλες οι υπηρεσίες όμως είναι εν
|
||||
δυνάμει ευάλωτες σε επιθέσεις εάν δε ληφθούν τα απαραίτητα μέτρα προστασίας και
|
||||
αφήσουν ανοιχτά σημεία εισόδου στο δίκτυο τους.
|
||||
|
||||
Η παρούσα εργασία έχει ως στόχο την ανάπτυξη ενός εργαλείου που επιτυγχάνει την
|
||||
αυτοματοποίηση τριών τομέων. Την επικοινωνία με τον πάροχο νέφους για την
|
||||
αίτηση διάθεσης υπολογιστικών πόρων, την ασφάλιση των πόρων αυτών και τέλος την
|
||||
εγκατάσταση, ασφάλιση και χρήση του Docker για τη διάθεση εφαρμογών που
|
||||
βρίσκονται στο Dockerhub. Το επίσημο αποθετήριο του Docker.
|
||||
|
||||
Στην παρούσα ενότητα θα γίνει αναφορά σε εργαλεία που έχουν αναπτυχθεί για έναν
|
||||
ή παραπάνω από αυτούς τους τρεις τομείς και θα πραγματοποιηθεί σύγκριση τους
|
||||
ανάλογα με τον τρόπο λειτουργίας τους και τις δυνατότητες που παρέχουν.
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
\chapter{Ανάπτυξη Συστήματος} \label{projectDevelopment}
|
||||
|
||||
\section{Αρχές και Πλαίσιο Σχεδίασης για ασφαλές στήσιμο υπηρεσιών σε μια ιδεατή μηχανή με χρήση της τεχνολογίας \textlatin{Docker}} \label{framework}
|
||||
\section{Αρχές και Πλαίσιο Σχεδίασης για ασφαλές στήσιμο υπηρεσιών σε μια ιδεατή μηχανή με χρήση της τεχνολογίας Docker} \label{framework}
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
\chapter{Εγκατάσταση \& Επίδειξη του εργαλείου \textlatin{SecDep}} \label{installationANDShowcase}
|
||||
\chapter{Εγκατάσταση \& Επίδειξη του εργαλείου SecDep} \label{installationANDShowcase}
|
||||
|
||||
\section{Υλοποίηση και Συστατικά Μέρη} \label{platform}
|
||||
|
||||
33
Declaration/declaration.tex
Normal file
33
Declaration/declaration.tex
Normal file
@@ -0,0 +1,33 @@
|
||||
\Declaration{
|
||||
\thispagestyle{empty} % also skip displaying numbering on this page
|
||||
\addtocontents{toc}{\vspace{1em}} % Add a gap in the Contents, for aesthetics
|
||||
|
||||
\noindent Εγώ, ο Χωλίδης Κωνσταντίνος, δηλώνω ότι αυτή η διπλωματική εργασία με
|
||||
τίτλο, Σκλήρυνση Μηχανής Δοχείων και Λειτουργικού Συστήματος σε Περιβάλλοντα
|
||||
Linux, και η δουλειά που παρουσιάζεται σε αυτή είναι δικά μου. Επιβεβαιώνω ότι:
|
||||
|
||||
\begin{itemize}
|
||||
\item[\tiny{$\blacksquare$}] Αυτή η δουλειά πραγματοποιήθηκε ολοκληρωτικά ή κυρίως κατά την υποψηφιότητά μου για τίτλο προπτυχιακών σπουδών σε αυτό το πανεπιστήμιο.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου οποιοδήποτε μέρος αυτής της πτυχιακής εργασίας έχει προηγουμένως κατατεθεί για την απόκτηση πτυχίου ή άλλου τίτλου σε αυτό ή άλλο πανεπιστήμιο, αυτό διατυπώνεται ξεκάθαρα.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω συμβουλευτεί την δημοσιευμένη δουλειά τρίτων, αυτό αποδίδεται ορθώς.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω παραθέσει από δουλειά τρίτων, η πηγή δίνεται πάντα. Με εξαίρεση αυτές τις παραθέσεις, αυτή η πτυχιακή εργασία είναι εξ ολοκλήρου προσωπική μου δουλειά.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Έχω παραθέσει όλες τις κύριες πηγές βοήθειας.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου αυτή η πτυχιακή εργασία είναι βασισμένη σε συνεργατική δουλειά δική μου και τρίτων, έχω καταστήσει ξεκάθαρο ποια κομμάτια έχουν πραγματοποιηθεί από άλλους και πώς συνέβαλα εγώ.
|
||||
% Alternative to "\\" without the "Underfull \hbox (badness 10000) in paragraph" error
|
||||
\vspace{\baselineskip}
|
||||
\end{itemize}
|
||||
|
||||
\vfill\vfill
|
||||
|
||||
Υπογραφή:\\
|
||||
\rule[1em]{25em}{0.5pt} % This prints a line for the signature
|
||||
|
||||
Ημερομηνία:\\
|
||||
\rule[1em]{25em}{0.5pt} % This prints a line to write the date
|
||||
}
|
||||
\clearpage % Declaration ended, now start a new page
|
||||
BIN
Figures/Enisa/enisaThreats.jpg
Normal file
BIN
Figures/Enisa/enisaThreats.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 235 KiB |
BIN
Figures/Enisa/enisaThreatsOLD.jpg
Normal file
BIN
Figures/Enisa/enisaThreatsOLD.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 153 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
Figures/VMWARE_Virtualization/vmware_memory_virtualization.png
Normal file
BIN
Figures/VMWARE_Virtualization/vmware_memory_virtualization.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
166
SettingsAndPackages/formatsAndDefs.tex
Normal file
166
SettingsAndPackages/formatsAndDefs.tex
Normal file
@@ -0,0 +1,166 @@
|
||||
\graphicspath{Figures/} % Location of the graphics files (set up for graphics to be in PDF format)
|
||||
|
||||
\usepackage[final]{microtype} % Improves character and word spacing
|
||||
|
||||
% Redifine how ' appears with current font
|
||||
|
||||
% In order to quote, better use \textquote{quote} instead of 'quote' since it
|
||||
% already did not work correctly with current font
|
||||
|
||||
%Math mode is not supported and will still print ’ instead of ' unless you
|
||||
%invoke \prime for an almost correct result
|
||||
|
||||
\catcode`\'=\active
|
||||
\def'{’}
|
||||
|
||||
% Table configuration packages
|
||||
% Extending the array and tabular environments, Enhanced support for graphics
|
||||
\usepackage{array,graphicx}
|
||||
% Publication quality tables in LaTeX
|
||||
\usepackage{booktabs}
|
||||
% Access to PostScript standard Symbol and Dingbats fonts
|
||||
\usepackage{pifont}
|
||||
% Flexible LaTeX tabulars
|
||||
\usepackage{tabu}
|
||||
% Allow tables to flow over page boundaries
|
||||
\usepackage{longtable}
|
||||
% Driver-independent color extensions for LaTeX and pdfLaTeX
|
||||
\usepackage{xcolor}
|
||||
% Coloured boxes, for LaTeX examples and theorems, etc
|
||||
\usepackage{tcolorbox}
|
||||
% LaTeX support for the Text Companion fonts
|
||||
\usepackage{textcomp}
|
||||
|
||||
% Select alternative section titles (Better chapter, section and subsection titles)
|
||||
\usepackage{titlesec}
|
||||
% Somehow messes up indentfirst for chapters only where it didn't before
|
||||
\titleformat{\chapter}[block]{\huge\bfseries\centering}{\chaptertitlename\ \thechapter.}{0.5em}{} % frame is also good as opposed to block
|
||||
\titleformat{\section}[hang]{\large\bfseries}{\thesection}{0.5em}{}
|
||||
\titleformat{\subsection}[hang]{\normalsize\bfseries}{\thesubsection}{0.5em}{}
|
||||
\titleformat{\subsubsection}[hang]{\normalsize\bfseries}{\thesubsubsection}{0.5em}{}
|
||||
\titlespacing{\chapter}{-5pt}{-1cm}{1cm} % How low the chapter title is
|
||||
% Better formatting of the chapter names in the table of contents
|
||||
\usepackage{titletoc}
|
||||
% \newcommand{\chaptitlefont}[1]{{\bfseries\Large #1}}
|
||||
|
||||
% Bellow is the same as the default settings but with : between the number and the title
|
||||
\titlecontents{chapter}% level to be modified
|
||||
[0pt]{\addvspace{0.3cm}}%
|
||||
{\textsc{\hspace{0cm}\normalsize\bfseries \thecontentslabel: }\normalsize\bfseries\chaptitlefont}
|
||||
{\normalsize\bfseries}% for star chapters
|
||||
{\hfill\bfseries\contentspage}
|
||||
[\addvspace{.2pc}]%
|
||||
|
||||
\PolyglossiaSetup{greek}{indentfirst=false} % Do not indent first paragraph
|
||||
|
||||
% Intermix single and multiple columns
|
||||
\usepackage{multicol}
|
||||
% Context sensitive quotation facilities
|
||||
\usepackage{csquotes} % Recommended with babel by biblatex
|
||||
% make \textquote add quotation marks as “…”
|
||||
\DeclareQuoteStyle{greek}{\textquotedblleft}{\textquotedblright}{\textquoteleft}{\textquoteright}
|
||||
% Improve on LaTeX's footnote handling
|
||||
\usepackage{footnote} % For footcite in tables
|
||||
% A range of footnote options
|
||||
\usepackage[bottom]{footmisc} % For footcite to be at the bottom of the page
|
||||
% \fancyhfinit{\mdseries\rmfamily} % Header font
|
||||
|
||||
% Fix caption font
|
||||
\usepackage{caption}
|
||||
\DeclareCaptionFont{myfont}{\selectlanguage{greek}\selectfont}
|
||||
\captionsetup{textfont=myfont}
|
||||
|
||||
\makeatother
|
||||
|
||||
% Include any extra LaTeX packages required
|
||||
% biblatex because it has foocite built-in
|
||||
% Sophisticated Bibliographies in LaTeX
|
||||
\usepackage[backend=biber,style=trad-abbrv,backref=true,autocite=plain,sorting=none,natbib=true]{biblatex} % Use the "Natbib" style for the references in the Bibliography
|
||||
|
||||
\DefineBibliographyStrings{greek}{
|
||||
backrefpage={Αναφορά στη σελίδα},
|
||||
backrefpages={Αναφορά στις σελίδες},
|
||||
}
|
||||
|
||||
%%% Print url and doi in a new line when on the bibliography page
|
||||
\newbibmacro*{bbx:parunit}{%
|
||||
\ifbibliography
|
||||
{\setunit{\bibpagerefpunct}\newblock
|
||||
\usebibmacro{pageref}%
|
||||
\clearlist{pageref}%
|
||||
\setunit{\adddot\par\nobreak}}
|
||||
{}}
|
||||
|
||||
\renewbibmacro*{doi+eprint+url}{%
|
||||
\usebibmacro{bbx:parunit}% Added
|
||||
\iftoggle{bbx:doi}
|
||||
{\printfield{doi}}
|
||||
{}%
|
||||
\iftoggle{bbx:eprint}
|
||||
{\usebibmacro{eprint}}
|
||||
{}%
|
||||
\iftoggle{bbx:url}
|
||||
{\usebibmacro{url+urldate}}
|
||||
{}}
|
||||
|
||||
\renewbibmacro*{eprint}{%
|
||||
\usebibmacro{bbx:parunit}% Added
|
||||
\iffieldundef{eprinttype}
|
||||
{\printfield{eprint}}
|
||||
{\printfield[eprint:\strfield{eprinttype}]{eprint}}}
|
||||
|
||||
\renewbibmacro*{url+urldate}{%
|
||||
\usebibmacro{bbx:parunit}% Added
|
||||
\printfield{url}%
|
||||
\iffieldundef{urlyear}
|
||||
{}
|
||||
{\setunit*{\addspace}%
|
||||
\printtext[urldate]{\printurldate}}}
|
||||
%%%
|
||||
|
||||
%%%%
|
||||
|
||||
% \newbibmacro*{cite:ibid}{%
|
||||
% \printtext{%
|
||||
% \bibhyperlink{cite\csuse{cbx@lastcite@\thefield{entrykey}}}{%
|
||||
% \bibstring[\mkibid]{ibidem}}}%
|
||||
% \ifloccit
|
||||
% {\global\toggletrue{cbx:loccit}}
|
||||
% {}}
|
||||
%
|
||||
% \renewbibmacro*{cite:ibid}{%
|
||||
% \printtext{%
|
||||
% \bibhyperlink{cite\csuse{cbx@lastcite@\thefield{entrykey}}}{%
|
||||
% \ifloccit
|
||||
% {\bibstring[\mkibid]{ibidem}%
|
||||
% \global\toggletrue{cbx:loccit}}
|
||||
% {\bibstring[\mkibid]{idem\thefield{gender}}}}}}
|
||||
|
||||
%%%%
|
||||
|
||||
\addbibresource{Bibliography.bib} % The references (bibliography) information are stored in the file named "Bibliography.bib"
|
||||
|
||||
% Reimplementation of and extensions to LaTeX verbatim
|
||||
\usepackage{verbatim} % Needed for the "comment" environment to make LaTeX comments
|
||||
% Improved interface for floating objects
|
||||
\usepackage{float} % To keep figures in place
|
||||
% Make sure to load hyperref last of your loaded packages, and that hypertexnames is true so
|
||||
% that bibliography backreferences work properly.
|
||||
\AtEndPreamble{\RequirePackage{hyperref}}
|
||||
\hypersetup{hypertexnames=true, urlcolor=black, colorlinks=false, pdfborder = {0 0 0}} % Colours hyperlinks in blue
|
||||
% Define enumerated description lists
|
||||
% Control layout of itemize, enumerate, description
|
||||
\usepackage{enumitem}
|
||||
\newcounter{descriptcount}
|
||||
\newcounter{descriptcount2}
|
||||
\newlist{enumdescript}{description}{2}
|
||||
\setlist[enumdescript,1]{%
|
||||
before={\setcounter{descriptcount}{0}%
|
||||
\renewcommand*\thedescriptcount{\arabic{descriptcount}.}}
|
||||
,font=\bfseries\stepcounter{descriptcount}\thedescriptcount~
|
||||
}
|
||||
\setlist[enumdescript,2]{%
|
||||
before={\setcounter{descriptcount2}{0}%
|
||||
\renewcommand*\thedescriptcount{\roman{descriptcount2}.}}
|
||||
,font=\bfseries\stepcounter{descriptcount2}\thedescriptcount~
|
||||
}
|
||||
54
Thesis.cls
54
Thesis.cls
@@ -3,10 +3,6 @@
|
||||
%% generated with the docstrip utility.
|
||||
%%
|
||||
%% Created by Steve R. Gunn, modified by Sunil Patel: www.sunilpatel.co.uk
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[greek]{babel}
|
||||
\usepackage{alphabeta}
|
||||
\usepackage[LGR, T1]{fontenc}
|
||||
|
||||
\NeedsTeXFormat{LaTeX2e}[1996/12/01]
|
||||
\ProvidesClass{Thesis}
|
||||
@@ -27,19 +23,32 @@
|
||||
\PassOptionsToClass{a4paper}{\baseclass}
|
||||
\ProcessOptions\relax
|
||||
\LoadClass{\baseclass}
|
||||
|
||||
\usepackage{polyglossia}
|
||||
\usepackage{fontspec}
|
||||
\defaultfontfeatures{Ligatures=TeX}
|
||||
\setmainfont{CMU Serif}
|
||||
\setsansfont{CMU Sans Serif}
|
||||
\setmonofont{CMU Typewriter Text}
|
||||
\setdefaultlanguage{greek}
|
||||
\newfontfamily\greekfont[Script=Greek]{CMU Serif}
|
||||
\setotherlanguage{english}
|
||||
% Fixes the wrong λ in some places like bibliography where we need textenglish for hyphenation rules
|
||||
\newfontfamily\englishfont[Script=Greek]{CMU Serif}
|
||||
|
||||
\newcommand\bhrule{\typeout{------------------------------------------------------------------------------}}
|
||||
|
||||
\newcommand\Declaration[1]{
|
||||
\btypeout{Declaration of Authorship}
|
||||
\addtotoc{Δήλωση Συγγραφικής Ιδιότητας}
|
||||
\thispagestyle{plain}
|
||||
\null\vfil
|
||||
%\vskip 60\p@
|
||||
\begin{center}{\huge\bf Δήλωση Συγγραφικής Ιδιότητας \par}\end{center}
|
||||
%\vskip 60\p@
|
||||
% \null\vfil
|
||||
% \vskip 60\p@
|
||||
\begin{center}{\huge\textbf Δήλωση Συγγραφικής Ιδιότητας \par}\end{center}
|
||||
\vskip 50\p@
|
||||
{\normalsize #1}
|
||||
\vfil\vfil\null
|
||||
%\cleardoublepage
|
||||
% \cleardoublepage
|
||||
}
|
||||
|
||||
\newcommand\btypeout[1]{\bhrule\typeout{\space #1}\bhrule}
|
||||
@@ -49,12 +58,12 @@
|
||||
\space \number\year}
|
||||
\usepackage{setspace}
|
||||
\onehalfspacing
|
||||
\setlength{\parindent}{0pt}
|
||||
\setlength{\parindent}{20pt} % Changed from 0pt
|
||||
\setlength{\parskip}{2.0ex plus0.5ex minus0.2ex}
|
||||
\usepackage{vmargin}
|
||||
\setmarginsrb { 1.5in} % left margin
|
||||
\setmarginsrb { 0.9in} % left margin % changed from 1.5in
|
||||
{ 0.6in} % top margin
|
||||
{ 1.0in} % right margin
|
||||
{ 0.8in} % right margin % changed from 1.0in
|
||||
{ 0.8in} % bottom margin
|
||||
{ 20pt} % head height
|
||||
{0.25in} % head sep
|
||||
@@ -94,12 +103,12 @@
|
||||
\newtheorem{remark}[theorem]{Remark}
|
||||
\usepackage[centerlast,small,sc]{caption}
|
||||
\setlength{\captionmargin}{20pt}
|
||||
\newcommand{\fref}[1]{Figure~\ref{#1}}
|
||||
\newcommand{\tref}[1]{Table~\ref{#1}}
|
||||
\newcommand{\eref}[1]{Equation~\ref{#1}}
|
||||
\newcommand{\cref}[1]{Chapter~\ref{#1}}
|
||||
\newcommand{\sref}[1]{Section~\ref{#1}}
|
||||
\newcommand{\aref}[1]{Appendix~\ref{#1}}
|
||||
% \newcommand{\fref}[1]{Figure~\ref{#1}}
|
||||
% \newcommand{\tref}[1]{Table~\ref{#1}}
|
||||
% \newcommand{\eref}[1]{Equation~\ref{#1}}
|
||||
% \newcommand{\cref}[1]{Chapter~\ref{#1}}
|
||||
% \newcommand{\sref}[1]{Section~\ref{#1}}
|
||||
% \newcommand{\aref}[1]{Appendix~\ref{#1}}
|
||||
\renewcommand{\topfraction}{0.85}
|
||||
\renewcommand{\bottomfraction}{.85}
|
||||
\renewcommand{\textfraction}{0.1}
|
||||
@@ -111,7 +120,6 @@
|
||||
\setcounter{totalnumber}{20}
|
||||
\setcounter{dbltopnumber}{9}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{epstopdf}
|
||||
\usepackage[scriptsize]{subfigure}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{rotating}
|
||||
@@ -187,16 +195,16 @@
|
||||
\let \footnote \thanks
|
||||
\setcounter{footnote}{0}
|
||||
\null\vfil
|
||||
\vskip 60\p@
|
||||
\vskip 0\p@
|
||||
\begin{center}
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[scale=0.2]{Figures/aegean_logo}
|
||||
\includegraphics[scale=0.15]{Figures/aegean_logo}
|
||||
\end{figure}
|
||||
\setlength{\parskip}{0pt}
|
||||
{\large\textbf{\UNIVNAME}\par}
|
||||
\vfill
|
||||
{\huge \bf \@title \par}
|
||||
{\huge \textbf \@title \par}
|
||||
\vfill
|
||||
{\LARGE του \par}
|
||||
\smallskip
|
||||
@@ -251,7 +259,7 @@
|
||||
\bigskip
|
||||
{\normalsize Προπτυχιακός Τίτλος Σπουδών\par}
|
||||
\bigskip
|
||||
{\normalsize\bf \@title \par}
|
||||
{\normalsize\bfseries \@title \par}
|
||||
\medskip
|
||||
{\normalsize του \authornames \par}
|
||||
\bigskip
|
||||
|
||||
161
Thesis.tex
161
Thesis.tex
@@ -3,48 +3,9 @@
|
||||
%% ----------------------------------------------------------------
|
||||
|
||||
% Set up the document
|
||||
\documentclass[a4paper, 11pt, oneside]{Thesis} % Use the "Thesis" style, based on the ECS Thesis style by Steve Gunn
|
||||
\graphicspath{Figures/} % Location of the graphics files (set up for graphics to be in PDF format)
|
||||
% Table configuration packages
|
||||
\usepackage{array,graphicx}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{pifont}
|
||||
\usepackage{tabu}
|
||||
\usepackage{longtable}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{tcolorbox}
|
||||
\usepackage{textcomp}
|
||||
% Υποστήριξη για ελληνικά
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[greek]{babel}
|
||||
\usepackage{alphabeta}
|
||||
\usepackage[LGR, T1]{fontenc}
|
||||
\usepackage{multicol}
|
||||
|
||||
\makeatother
|
||||
|
||||
% Include any extra LaTeX packages required
|
||||
\usepackage[square, numbers, comma, sort, compress]{natbib} % Use the "Natbib" style for the references in the Bibliography
|
||||
\usepackage{verbatim} % Needed for the "comment" environment to make LaTeX comments
|
||||
\usepackage{float} % To keep figures in place
|
||||
\hypersetup{urlcolor=black, colorlinks=false, pdfborder = {0 0 0}} % Colours hyperlinks in blue
|
||||
% Define enumerated description lists
|
||||
\usepackage{enumitem}
|
||||
\newcounter{descriptcount}
|
||||
\newcounter{descriptcount2}
|
||||
\newlist{enumdescript}{description}{2}
|
||||
\setlist[enumdescript,1]{%
|
||||
before={\setcounter{descriptcount}{0}%
|
||||
\renewcommand*\thedescriptcount{\arabic{descriptcount}.}}
|
||||
,font=\bfseries\stepcounter{descriptcount}\thedescriptcount~
|
||||
}
|
||||
\setlist[enumdescript,2]{%
|
||||
before={\setcounter{descriptcount2}{0}%
|
||||
\renewcommand*\thedescriptcount{\roman{descriptcount2}.}}
|
||||
,font=\bfseries\stepcounter{descriptcount2}\thedescriptcount~
|
||||
}
|
||||
|
||||
\documentclass[a4paper, 12pt, oneside]{Thesis} % Use the "Thesis" style, based on the ECS Thesis style by Steve Gunn
|
||||
|
||||
\input{SettingsAndPackages/formatsAndDefs} % Include settings and custom commands
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\begin{document}
|
||||
@@ -54,7 +15,7 @@
|
||||
%\pagenumbering{arabic}
|
||||
|
||||
% Set up the Title Page
|
||||
\title {Σκλήρυνση Μηχανής Δοχείων και Λειτουργικού Συστήματος σε Περιβάλλοντα \textlatin{Linux}}
|
||||
\title{Σκλήρυνση Μηχανής Δοχείων και Λειτουργικού Συστήματος σε Περιβάλλοντα Linux}
|
||||
|
||||
\authors {\texorpdfstring
|
||||
{\href{mailto:icsd16221@aegean.gr}{Χωλίδης Κωνσταντίνος - 321/2016221}}
|
||||
@@ -63,7 +24,7 @@
|
||||
\addresses {\groupname\\\deptname\\\univname} % Do not change this here, instead these must be set in the "Thesis.cls" file, please look through it instead
|
||||
\date {Σάμος, Ιούλιος 2022}
|
||||
\subject {}
|
||||
\keywords {}
|
||||
\keywords {docker, linux, security, virtualization, cloud, hardening, containers, virtual machines}
|
||||
|
||||
\maketitle
|
||||
|
||||
@@ -80,36 +41,8 @@
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
% Declaration Page required for the Thesis, your institution may give you a different text to place here
|
||||
\Declaration{
|
||||
|
||||
\addtocontents{toc}{\vspace{1em}} % Add a gap in the Contents, for aesthetics
|
||||
|
||||
Εγώ, ο Χωλίδης Κωνσταντίνος, δηλώνω ότι αυτή η διπλωματική εργασία με τίτλο, Σκλήρυνση Μηχανής Δοχείων και Λειτουργικού Συστήματος σε Περιβάλλοντα \textlatin{Linux}, και η δουλειά που παρουσιάζεται σε αυτή είναι δικά μου. Επιβεβαιώνω ότι:
|
||||
|
||||
\begin{itemize}
|
||||
\item[\tiny{$\blacksquare$}] Αυτή η δουλειά πραγματοποιήθηκε ολοκληρωτικά ή κυρίως κατά την υποψηφιότητά μου για τίτλο προπτυχιακών σπουδών σε αυτό το πανεπιστήμιο.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου οποιοδήποτε μέρος αυτής της πτυχιακής εργασίας έχει προηγουμένως κατατεθεί για την απόκτηση πτυχίου ή άλλου τίτλου σε αυτό ή άλλο πανεπιστήμιο, αυτό διατυπώνεται ξεκάθαρα.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω συμβουλευτεί την δημοσιευμένη δουλειά τρίτων, αυτό αποδίδεται ορθώς.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω παραθέσει από δουλειά τρίτων, η πηγή δίνεται πάντα. Με εξαίρεση αυτές τις παραθέσεις, αυτή η πτυχιακή εργασία είναι εξ ολοκλήρου προσωπική μου δουλειά.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Έχω παραθέσει όλες τις κύριες πηγές βοήθειας.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου αυτή η πτυχιακή εργασία είναι βασισμένη σε συνεργατική δουλειά δική μου και τρίτων, έχω καταστήσει ξεκάθαρο ποια κομμάτια έχουν πραγματοποιηθεί από άλλους και πώς συνέβαλα εγώ.
|
||||
% Alternative to "\\" without the "Underfull \hbox (badness 10000) in paragraph" error
|
||||
\vspace{\baselineskip}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
Υπογραφή:\\
|
||||
\rule[1em]{25em}{0.5pt} % This prints a line for the signature
|
||||
|
||||
Ημερομηνία:\\
|
||||
\rule[1em]{25em}{0.5pt} % This prints a line to write the date
|
||||
}
|
||||
\clearpage % Declaration ended, now start a new page
|
||||
\input{Declaration/declaration} % Include the declaration page
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
% The "Funny Quote Page"
|
||||
@@ -117,10 +50,10 @@
|
||||
|
||||
\null\vfill
|
||||
% Now comes the "Funny Quote", written in italics
|
||||
\textit{\textlatin{Απόφθεγμα (προαιρετικό)}}
|
||||
\textquote{\textit{UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.}}
|
||||
|
||||
\begin{flushright}
|
||||
\textlatin{Συγγραφέας Αποφθέγματος}
|
||||
Dennis Ritchie (1941 - 2011)
|
||||
\end{flushright}
|
||||
|
||||
\vfill\vfill\vfill\vfill\vfill\vfill\null
|
||||
@@ -128,37 +61,9 @@
|
||||
%% ----------------------------------------------------------------
|
||||
|
||||
% The Abstract Page
|
||||
\addtotoc{Σύνοψη} % Add the "Abstract" page entry to the Contents
|
||||
\abstract{
|
||||
\addtocontents{toc}{\vspace{1em}} % Add a gap in the Contents, for aesthetics
|
||||
|
||||
Τη σήμερον ημέρα όλο και περισσότερος κόσμος βασίζεται πλέον σε υπηρεσίες τύπου
|
||||
\textlatin{IaaS} έναντι των παραδοσιακών \textlatin{Server Room} για τις
|
||||
υποδομές υπηρεσιών. Αυτό συμβαίνει διότι κατ'' αυτό τον τρόπο μειώνονται τα
|
||||
λειτουργικά έξοδα μιας και δεν υπάρχει ανάγκη δαπάνης για την αγορά εξοπλισμού
|
||||
για την έναρξη διάθεσης της εκάστοτε υπηρεσίας αλλά είναι πλέον δυνατό να
|
||||
κλιμακωθεί ανάλογα με τις ανάγκες των χρηστών της υπηρεσίας που προσφέρεται με
|
||||
μια απλή και γρήγορη επανεκκίνηση της εικονικής μηχανής χρησιμοποιώντας νέες
|
||||
παραμέτρους. Με αυτόν τον τρόπο μεταβιβάζεται η ευθύνη της συντήρησης
|
||||
εξοπλισμού σε τρίτους αλλά ταυτόχρονα εισάγεται ένα καινούριο μοντέλο
|
||||
εμπιστοσύνης ανάμεσα όχι μόνο στον χρήστη και τον πάροχο νέφους αλλά και αυτόν
|
||||
που παρέχει τις πολλές φορές προ ρυθμισμένες διανομές \textlatin{Linux} σε
|
||||
αυτόν.
|
||||
\input{Abstract/abstract} % Include the abstract page
|
||||
|
||||
Στην παρούσα εργασία θα αναλύσουμε τις τρωτότητες μιας ιδεατής μηχανής και
|
||||
τρόπους για την αντιμετώπισή τους. Έπειτα θα μιλήσουμε για την τεχνολογία
|
||||
\textlatin{Docker} και το πως μπορεί να γίνει χρήση της με μεγαλύτερη ασφάλεια.
|
||||
Ο σκοπός της εργασίας είναι η δημιουργία ενός εργαλείου που θα μπορεί όχι μόνο
|
||||
να δημιουργεί ιδεατές μηχανές κατά μήκος πολλών παρόχων νέφους αλλά και να τις
|
||||
σκληραίνει με έναν αυτοματοποιημένο τρόπο. Επιπροσθέτως θα εγκαθιστά σε αυτές
|
||||
τη μηχανή δοχείων \textlatin{Docker} την οποία επίσης θα σκληραίνει με σκοπό το
|
||||
εύκολο στήσιμο υπηρεσιών με ασφαλή τρόπο για οποιονδήποτε χρήστη ανεξαρτήτως
|
||||
επιπέδου γνώσεων στον τομέα της ασφάλειας και των λειτουργικών συστημάτων τύπου
|
||||
\textlatin{Unix}.
|
||||
|
||||
}
|
||||
|
||||
\clearpage % Abstract ended, start a new page
|
||||
%% ----------------------------------------------------------------
|
||||
|
||||
\setstretch{1.3} % Reset the line-spacing to 1.3 for body text (if it has changed)
|
||||
@@ -169,37 +74,30 @@
|
||||
|
||||
Εδώ γράφονται οι ευχαριστίες.
|
||||
|
||||
|
||||
}
|
||||
\clearpage % End of the Acknowledgements
|
||||
%% ----------------------------------------------------------------
|
||||
|
||||
\pagestyle{fancy} %The page style headers have been "empty" all this time, now use the "fancy" headers as defined before to bring them back
|
||||
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\lhead{\emph{Περιεχόμενα}} % Set the left side page header to "Contents"
|
||||
% Changed all \emph to \textgreek to get the corrext font
|
||||
\lhead{\textgreek{Περιεχόμενα}} % Set the left side page header to "Contents"
|
||||
\tableofcontents % Write out the Table of Contents
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\lhead{\emph{Κατάλογος Σχημάτων}} % Set the left side page header to "List if Figures"
|
||||
|
||||
\lhead{\textgreek{Κατάλογος Σχημάτων}} % Set the left side page header to "List if Figures"
|
||||
\listoffigures % Write out the List of Figures
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\lhead{\emph{Κατάλογος Πινάκων}} % Set the left side page header to "List of Tables"
|
||||
\lhead{\textgreek{Κατάλογος Πινάκων}} % Set the left side page header to "List of Tables"
|
||||
\listoftables % Write out the List of Tables
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\setstretch{1.5} % Set the line spacing to 1.5, this makes the following tables easier to read
|
||||
\clearpage % Start a new page
|
||||
\lhead{\emph{Συντομογραφίες}} % Set the left side page header to "Abbreviations"
|
||||
\listofsymbols{ll} % Include a list of Abbreviations (a table of two columns)
|
||||
{
|
||||
% \textbf{Acronym} & \textbf{W}hat (it) \textbf{S}tands \textbf{F}or \\
|
||||
% Εδώ μπαίνουν οι συντομογραφίες
|
||||
}
|
||||
|
||||
\lhead{}
|
||||
\input{Abbreviations/abbreviations} % Include a list of abbreviations (a table of two columns)
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
% End of the pre-able, contents and lists of things
|
||||
% Begin the Dedication page
|
||||
@@ -211,7 +109,6 @@
|
||||
|
||||
\addtocontents{toc}{\vspace{2em}} % Add a gap in the Contents, for aesthetics
|
||||
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\mainmatter % Begin normal, numeric (1,2,3...) page numbering
|
||||
\pagestyle{fancy} % Return the page headers back to the "fancy" style
|
||||
@@ -225,16 +122,14 @@
|
||||
|
||||
\input{Chapters/3.RelevantWork} % Relevant Work
|
||||
|
||||
\input{Chapters/4.ProjectDevelopment} % Framework
|
||||
\input{Chapters/4.ProjectDevelopment} % Project Development
|
||||
|
||||
\input{Chapters/5.ProjectShowcase} % Project
|
||||
\input{Chapters/5.ProjectShowcase} % Project Showcase
|
||||
|
||||
\input{Chapters/6.Experimentation} % Experiment 2
|
||||
\input{Chapters/6.Experimentation} % Metrics
|
||||
|
||||
\input{Chapters/7.Conclusions} % Results and Discussion
|
||||
|
||||
%\input{Chapters/Chapter7} % Conclusion
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
% Now begin the Appendices, including them as separate files
|
||||
|
||||
@@ -248,14 +143,22 @@
|
||||
|
||||
\addtocontents{toc}{\vspace{2em}} % Add a gap in the Contents, for aesthetics
|
||||
|
||||
|
||||
%% ----------------------------------------------------------------
|
||||
\label{Bibliography}
|
||||
\lhead{\emph{Βιβλιογραφία}} % Change the left side page header to "Bibliography"
|
||||
\bibliographystyle{ACM-Reference-Format}
|
||||
% \bibliographystyle{unsrtnat} % Use the "unsrtnat" BibTeX style for formatting the Bibliography
|
||||
\textlatin{
|
||||
\bibliography{Bibliography} % The references (bibliography) information are stored in the file named "Bibliography.bib"
|
||||
\lhead{\textgreek{Βιβλιογραφία}} % Change the left side page header to "Bibliography"
|
||||
\renewcommand*{\bibfont}{\textbf\small} % Have the correct font
|
||||
|
||||
% So far the settings bellow in conjunction with the microtype package fix the overflow and underflow of the bibliography
|
||||
|
||||
% If you want to break on URL numbers
|
||||
\setcounter{biburlnumpenalty}{9000}
|
||||
% If you want to break on URL lower case letters
|
||||
\setcounter{biburllcpenalty}{9000}
|
||||
% If you want to break on URL UPPER CASE letters
|
||||
\setcounter{biburlucpenalty}{9000}
|
||||
|
||||
\textenglish{ % Majority of the bibliography is in english so we need the english hyphenation
|
||||
\printbibliography[title={Βιβλιογραφία}]
|
||||
}
|
||||
\end{document} % The End
|
||||
%% ----------------------------------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user