Η ουσία της ιστορίας σχετικά με τον πιο δημοφιλή διαχειριστή πακέτων για το Kubernetes θα μπορούσε να απεικονιστεί χρησιμοποιώντας ένα emoji:
- το κουτί είναι Helm (που είναι το πιο κοντινό πράγμα στην τελευταία έκδοση Emoji).
- κλειδαριά - ασφάλεια?
- το ανθρωπάκι είναι η λύση στο πρόβλημα.
Στην πραγματικότητα, όλα θα είναι λίγο πιο περίπλοκα και η ιστορία είναι γεμάτη τεχνικές λεπτομέρειες Πώς να κάνετε το Helm ασφαλές.
- Εν συντομία τι είναι το Helm σε περίπτωση που δεν το ξέρατε ή το ξεχάσατε. Τι προβλήματα λύνει και πού βρίσκεται στο οικοσύστημα.
- Ας δούμε την αρχιτεκτονική του Helm. Καμία συζήτηση σχετικά με την ασφάλεια και το πώς να κάνετε ένα εργαλείο ή μια λύση πιο ασφαλή δεν είναι ολοκληρωμένη χωρίς να κατανοήσετε την αρχιτεκτονική του στοιχείου.
- Ας συζητήσουμε τα εξαρτήματα του Helm.
- Το πιο φλέγον ερώτημα είναι το μέλλον - η νέα έκδοση του Helm 3.
Όλα σε αυτό το άρθρο ισχύουν για το Helm 2. Αυτή η έκδοση είναι προς το παρόν σε παραγωγή και είναι πιθανότατα αυτή που χρησιμοποιείτε αυτήν τη στιγμή και είναι η έκδοση που περιέχει τους κινδύνους ασφαλείας.
Σχετικά με τον ομιλητή: Alexander Khayorov () αναπτύσσεται εδώ και 10 χρόνια, συμβάλλοντας στη βελτίωση του περιεχομένου και εντάχθηκε στην επιτροπή . Τώρα εργάζεται στο Chainstack ως επικεφαλής ανάπτυξης - αυτό είναι ένα υβρίδιο μεταξύ ενός διευθυντή ανάπτυξης και ενός ατόμου που είναι υπεύθυνο για την παράδοση των τελικών εκδόσεων. Βρίσκεται δηλαδή στο πεδίο της μάχης, όπου συμβαίνουν τα πάντα από τη δημιουργία ενός προϊόντος μέχρι τη λειτουργία του.
Η Chainstack είναι μια μικρή, ενεργά αναπτυσσόμενη startup της οποίας η αποστολή είναι να επιτρέπει στους πελάτες να ξεχνούν την υποδομή και την πολυπλοκότητα της λειτουργίας αποκεντρωμένων εφαρμογών· η ομάδα ανάπτυξης βρίσκεται στη Σιγκαπούρη. Μην ζητήσετε από το Chainstack να πουλήσει ή να αγοράσει κρυπτονομίσματα, αλλά προσφερθείτε να μιλήσετε για εταιρικά πλαίσια blockchain και θα σας απαντήσουν ευχαρίστως.
Πηδάλιο
Αυτός είναι ένας διαχειριστής πακέτων (γραφήματος) για την Kubernetes. Ο πιο διαισθητικός και καθολικός τρόπος για να φέρετε εφαρμογές σε ένα σύμπλεγμα Kubernetes.
Μιλάμε, φυσικά, για μια πιο δομική και βιομηχανική προσέγγιση από το να δημιουργήσετε τα δικά σας μανιφέστα YAML και να γράψετε μικρά βοηθητικά προγράμματα.
Το τιμόνι είναι το καλύτερο που είναι σήμερα διαθέσιμο και δημοφιλές.
Γιατί Helm; Πρωτίστως γιατί υποστηρίζεται από το CNCF. Το Cloud Native είναι ένας μεγάλος οργανισμός και είναι η μητρική εταιρεία για έργα Kubernetes, etcd, Fluentd και άλλα.
Ένα άλλο σημαντικό γεγονός είναι ότι το Helm είναι ένα πολύ δημοφιλές έργο. Όταν άρχισα να μιλάω για το πώς να κάνω το Helm ασφαλές τον Ιανουάριο του 2019, το έργο είχε χίλια αστέρια στο GitHub. Μέχρι τον Μάιο υπήρχαν 12 χιλιάδες από αυτούς.
Πολλοί άνθρωποι ενδιαφέρονται για το Helm, οπότε ακόμα κι αν δεν το χρησιμοποιήσετε ακόμα, θα επωφεληθείτε από τη γνώση της ασφάλειάς του. Η ασφάλεια είναι σημαντική.
Η βασική ομάδα Helm υποστηρίζεται από το Microsoft Azure και επομένως είναι ένα αρκετά σταθερό έργο, σε αντίθεση με πολλά άλλα. Η κυκλοφορία του Helm 3 Alpha 2 στα μέσα Ιουλίου δείχνει ότι υπάρχουν πολλοί άνθρωποι που εργάζονται στο έργο και έχουν την επιθυμία και την ενέργεια να αναπτύξουν και να βελτιώσουν το Helm.
Η Helm επιλύει πολλά βασικά προβλήματα διαχείρισης εφαρμογών στο Kubernetes.
- Συσκευασία εφαρμογής. Ακόμη και μια εφαρμογή όπως το "Hello, World" στο WordPress αποτελείται ήδη από πολλές υπηρεσίες και θέλετε να τις συσκευάσετε μαζί.
- Διαχείριση της πολυπλοκότητας που συνεπάγεται η διαχείριση αυτών των εφαρμογών.
- Ένας κύκλος ζωής που δεν τελειώνει μετά την εγκατάσταση ή την ανάπτυξη της εφαρμογής. Συνεχίζει να ζει, πρέπει να ενημερωθεί, και η Helm βοηθά σε αυτό και προσπαθεί να φέρει τα σωστά μέτρα και πολιτικές για αυτό.
Σακκόπανο είναι οργανωμένο με σαφή τρόπο: υπάρχουν μεταδεδομένα σε πλήρη συμφωνία με το έργο ενός κανονικού διαχειριστή πακέτων για Linux, Windows ή MacOS. Δηλαδή, ένα αποθετήριο, εξαρτήσεις από διάφορα πακέτα, μετα-πληροφορίες για εφαρμογές, ρυθμίσεις, δυνατότητες διαμόρφωσης, ευρετηρίαση πληροφοριών κ.λπ. Το Helm σας επιτρέπει να αποκτήσετε και να χρησιμοποιήσετε όλα αυτά για εφαρμογές.
Διαχείριση πολυπλοκότητας. Εάν έχετε πολλές εφαρμογές του ίδιου τύπου, τότε απαιτείται παραμετροποίηση. Τα πρότυπα προέρχονται από αυτό, αλλά για να αποφύγετε να βρείτε τον δικό σας τρόπο δημιουργίας προτύπων, μπορείτε να χρησιμοποιήσετε ό,τι προσφέρει η Helm από το κουτί.
Διαχείριση Κύκλου Ζωής Εφαρμογών - κατά τη γνώμη μου, αυτό είναι το πιο ενδιαφέρον και άλυτο ερώτημα. Αυτός είναι ο λόγος που ήρθα στο Helm την προηγούμενη μέρα. Έπρεπε να παρακολουθούμε τον κύκλο ζωής της εφαρμογής και θέλαμε να μετακινήσουμε τους κύκλους CI/CD και εφαρμογών σε αυτό το παράδειγμα.
Το Helm σας επιτρέπει να:
- διαχείριση των αναπτύξεων, εισάγει την έννοια της διαμόρφωσης και της αναθεώρησης.
- πραγματοποιήσει με επιτυχία επαναφορά.
- χρησιμοποιήστε γάντζους για διαφορετικά γεγονότα.
- προσθέστε πρόσθετους ελέγχους εφαρμογών και απαντήστε στα αποτελέσματά τους.
Εξάλλου Το τιμόνι έχει "μπαταρίες" - ένας τεράστιος αριθμός νόστιμων πραγμάτων που μπορούν να συμπεριληφθούν με τη μορφή πρόσθετων, απλοποιώντας τη ζωή σας. Τα πρόσθετα μπορούν να γραφτούν ανεξάρτητα, είναι αρκετά απομονωμένα και δεν απαιτούν αρμονική αρχιτεκτονική. Εάν θέλετε να εφαρμόσετε κάτι, σας συνιστώ να το κάνετε ως πρόσθετο και, στη συνέχεια, ενδεχομένως να το συμπεριλάβετε στο upstream.
Το Helm βασίζεται σε τρεις βασικές έννοιες:
- Chart Repo — περιγραφή και σειρά παραμετροποιήσεων που είναι δυνατές για το μανιφέστο σας.
- Config — δηλαδή τις τιμές που θα εφαρμοστούν (κείμενο, αριθμητικές τιμές κ.λπ.).
- Απελευθερώστε συλλέγει τα δύο ανώτερα στοιχεία και μαζί μετατρέπονται σε Release. Οι εκδόσεις μπορούν να εκδοθούν, επιτυγχάνοντας έτσι έναν οργανωμένο κύκλο ζωής: μικρό κατά τη στιγμή της εγκατάστασης και μεγάλο κατά τη στιγμή της αναβάθμισης, της υποβάθμισης ή της επαναφοράς.
Αρχιτεκτονική του τιμονιού
Το διάγραμμα απεικονίζει εννοιολογικά την αρχιτεκτονική υψηλού επιπέδου του Helm.
Να σας θυμίσω ότι το Helm είναι κάτι που σχετίζεται με το Kubernetes. Επομένως, δεν μπορούμε να κάνουμε χωρίς ένα σύμπλεγμα Kubernetes (ορθογώνιο). Το στοιχείο kube-apiserver βρίσκεται στο master. Χωρίς Helm έχουμε Kubeconfig. Το Helm φέρνει ένα μικρό δυαδικό, αν μπορείτε να το ονομάσετε έτσι, το βοηθητικό πρόγραμμα Helm CLI, το οποίο είναι εγκατεστημένο σε υπολογιστή, φορητό υπολογιστή, κεντρικό υπολογιστή - σε οτιδήποτε.
Αυτό όμως δεν είναι αρκετό. Το Helm έχει ένα στοιχείο διακομιστή που ονομάζεται Tiller. Αντιπροσωπεύει τα συμφέροντα του Helm μέσα στο σύμπλεγμα· είναι μια εφαρμογή εντός του συμπλέγματος Kubernetes, όπως και κάθε άλλη.
Το επόμενο στοιχείο του Chart Repo είναι ένα αποθετήριο με γραφήματα. Υπάρχει ένα επίσημο αποθετήριο και μπορεί να υπάρχει ένα ιδιωτικό αποθετήριο μιας εταιρείας ή ενός έργου.
Αλληλεπίδραση
Ας δούμε πώς αλληλεπιδρούν τα στοιχεία της αρχιτεκτονικής όταν θέλουμε να εγκαταστήσουμε μια εφαρμογή χρησιμοποιώντας το Helm.
- Μιλάμε
Helm install, αποκτήστε πρόσβαση στο αποθετήριο (Chart Repo) και λάβετε ένα γράφημα Helm.
- Το βοηθητικό πρόγραμμα Helm (Helm CLI) αλληλεπιδρά με το Kubeconfig για να καταλάβει με ποιο σύμπλεγμα να επικοινωνήσετε.
- Έχοντας λάβει αυτές τις πληροφορίες, το βοηθητικό πρόγραμμα αναφέρεται στο Tiller, το οποίο βρίσκεται στο σύμπλεγμα μας, ως εφαρμογή.
- Ο Tiller καλεί τον Kube-apiserver για να εκτελέσει ενέργειες στο Kubernetes, να δημιουργήσει κάποια αντικείμενα (υπηρεσίες, pods, αντίγραφα, μυστικά κ.λπ.).
Στη συνέχεια, θα περιπλέκουμε το διάγραμμα για να δούμε το διάνυσμα επίθεσης στο οποίο μπορεί να εκτεθεί ολόκληρη η αρχιτεκτονική Helm στο σύνολό της. Και μετά θα προσπαθήσουμε να την προστατέψουμε.
Διάνυσμα επίθεσης
Το πρώτο πιθανό αδύναμο σημείο είναι προνομιούχο API-χρήστη. Ως μέρος του συστήματος, αυτός είναι ένας χάκερ που έχει αποκτήσει πρόσβαση διαχειριστή στο Helm CLI.
Μη προνομιούχος χρήστης API μπορεί επίσης να αποτελέσει κίνδυνο εάν βρίσκεται κάπου κοντά. Ένας τέτοιος χρήστης θα έχει διαφορετικό περιβάλλον, για παράδειγμα, μπορεί να διορθωθεί σε ένα χώρο ονομάτων συμπλέγματος στις ρυθμίσεις Kubeconfig.
Το πιο ενδιαφέρον διάνυσμα επίθεσης μπορεί να είναι μια διεργασία που βρίσκεται μέσα σε ένα σύμπλεγμα κάπου κοντά στο Tiller και μπορεί να έχει πρόσβαση σε αυτό. Αυτό μπορεί να είναι ένας διακομιστής ιστού ή μια μικρουπηρεσία που βλέπει το περιβάλλον δικτύου του συμπλέγματος.
Μια εξωτική, αλλά ολοένα και πιο δημοφιλής παραλλαγή επίθεσης περιλαμβάνει το Chart Repo. Ένα γράφημα που έχει δημιουργηθεί από έναν αδίστακτο συγγραφέα μπορεί να περιέχει μη ασφαλείς πόρους και θα το ολοκληρώσετε λαμβάνοντας πίστη. Ή μπορεί να αντικαταστήσει το γράφημα που κατεβάζετε από το επίσημο αποθετήριο και, για παράδειγμα, να δημιουργήσει έναν πόρο με τη μορφή πολιτικών και να κλιμακώσει την πρόσβασή του.
Ας προσπαθήσουμε να αποκρούσουμε τις επιθέσεις και από αυτές τις τέσσερις πλευρές και να καταλάβουμε πού υπάρχουν προβλήματα στην αρχιτεκτονική του Helm και πού, ίσως, δεν υπάρχουν.
Ας μεγεθύνουμε το διάγραμμα, ας προσθέσουμε περισσότερα στοιχεία, αλλά κρατάμε όλα τα βασικά στοιχεία.
Το Helm CLI επικοινωνεί με το Chart Repo, αλληλεπιδρά με το Kubeconfig και η εργασία μεταφέρεται στο σύμπλεγμα στο στοιχείο Tiller.
Ο Tiller αντιπροσωπεύεται από δύο αντικείμενα:
- Tiller-deploy svc, το οποίο εκθέτει μια συγκεκριμένη υπηρεσία.
- Tiller-deploy pod (στο διάγραμμα σε ένα μόνο αντίγραφο σε ένα αντίγραφο), στο οποίο εκτελείται ολόκληρο το φορτίο, το οποίο έχει πρόσβαση στο σύμπλεγμα.
Για την αλληλεπίδραση χρησιμοποιούνται διαφορετικά πρωτόκολλα και σχήματα. Από την άποψη της ασφάλειας, μας ενδιαφέρει περισσότερο:
- Ο μηχανισμός με τον οποίο το Helm CLI έχει πρόσβαση στο αποθετήριο γραφημάτων: ποιο πρωτόκολλο, υπάρχει έλεγχος ταυτότητας και τι μπορεί να γίνει με αυτό.
- Το πρωτόκολλο με το οποίο το Helm CLI, χρησιμοποιώντας kubectl, επικοινωνεί με τον Tiller. Αυτός είναι ένας διακομιστής RPC που είναι εγκατεστημένος μέσα στο σύμπλεγμα.
- Το ίδιο το Tiller είναι προσβάσιμο σε μικροϋπηρεσίες που βρίσκονται στο σύμπλεγμα και αλληλεπιδρά με τον διακομιστή Kube-apiserver.
Ας συζητήσουμε όλους αυτούς τους τομείς με τη σειρά.
RBAC
Δεν έχει νόημα να μιλάμε για ασφάλεια για το Helm ή οποιαδήποτε άλλη υπηρεσία εντός του συμπλέγματος, εκτός εάν είναι ενεργοποιημένο το RBAC.
Φαίνεται ότι αυτή δεν είναι η πιο πρόσφατη σύσταση, αλλά είμαι βέβαιος ότι πολλοί άνθρωποι εξακολουθούν να μην έχουν ενεργοποιήσει το RBAC ακόμη και στην παραγωγή, επειδή είναι πολύ φασαρία και πολλά πράγματα πρέπει να ρυθμιστούν. Ωστόσο, σας ενθαρρύνω να το κάνετε αυτό.
— δικηγόρος ιστότοπου για την RBAC. Περιέχει μια τεράστια ποσότητα από ενδιαφέροντα υλικά που θα σας βοηθήσουν να στήσετε το RBAC, να δείξετε γιατί είναι καλό και πώς να ζήσετε βασικά με αυτό στην παραγωγή.
Θα προσπαθήσω να εξηγήσω πώς λειτουργούν το Tiller και το RBAC. Το Tiller λειτουργεί μέσα στο σύμπλεγμα κάτω από έναν συγκεκριμένο λογαριασμό υπηρεσίας. Συνήθως, εάν το RBAC δεν έχει ρυθμιστεί, αυτός θα είναι ο υπερχρήστης. Στη βασική διαμόρφωση, ο Tiller θα είναι διαχειριστής. Αυτός είναι ο λόγος για τον οποίο λέγεται συχνά ότι το Tiller είναι μια σήραγγα SSH στο σύμπλεγμα σας. Στην πραγματικότητα, αυτό ισχύει, επομένως μπορείτε να χρησιμοποιήσετε έναν ξεχωριστό λογαριασμό αποκλειστικής υπηρεσίας αντί για τον προεπιλεγμένο λογαριασμό υπηρεσίας στο παραπάνω διάγραμμα.
Όταν αρχικοποιήσετε το Helm και το εγκαταστήσετε στον διακομιστή για πρώτη φορά, μπορείτε να ορίσετε τον λογαριασμό υπηρεσίας χρησιμοποιώντας --service-account. Αυτό θα σας επιτρέψει να χρησιμοποιήσετε έναν χρήστη με το ελάχιστο απαιτούμενο σύνολο δικαιωμάτων. Είναι αλήθεια ότι θα πρέπει να δημιουργήσετε μια τέτοια "γιρλάντα": Role και RoleBinding.
Δυστυχώς, ο Helm δεν θα το κάνει αυτό για εσάς. Εσείς ή ο διαχειριστής του συμπλέγματος Kubernetes πρέπει να προετοιμάσετε εκ των προτέρων ένα σύνολο Ρόλων και RoleBindings για τον λογαριασμό υπηρεσίας για να περάσετε το Helm.
Τίθεται το ερώτημα - ποια είναι η διαφορά μεταξύ του Role και του ClusterRole; Η διαφορά είναι ότι το ClusterRole λειτουργεί για όλους τους χώρους ονομάτων, σε αντίθεση με τα κανονικά Roles και RoleBindings, τα οποία λειτουργούν μόνο για έναν εξειδικευμένο χώρο ονομάτων. Μπορείτε να διαμορφώσετε πολιτικές για ολόκληρο το σύμπλεγμα και όλους τους χώρους ονομάτων ή να εξατομικεύσετε για κάθε χώρο ονομάτων ξεχωριστά.
Αξίζει να αναφέρουμε ότι το RBAC λύνει ένα ακόμη μεγάλο πρόβλημα. Πολλοί άνθρωποι παραπονιούνται ότι η Helm, δυστυχώς, δεν είναι πολυμίσθωση (δεν υποστηρίζει την πολυμίσθωση). Εάν πολλές ομάδες καταναλώνουν ένα σύμπλεγμα και χρησιμοποιούν το Helm, είναι βασικά αδύνατο να ορίσετε πολιτικές και να περιορίσετε την πρόσβασή τους σε αυτό το σύμπλεγμα, επειδή υπάρχει ένας συγκεκριμένος λογαριασμός υπηρεσίας στον οποίο εκτελείται το Helm και δημιουργεί όλους τους πόρους στο σύμπλεγμα από κάτω από αυτό , που μερικές φορές είναι πολύ άβολο. Αυτό ισχύει - όπως το ίδιο το δυαδικό αρχείο, όπως η διαδικασία, Ο Helm Tiller δεν έχει ιδέα πολυμίσθωσης.
Ωστόσο, υπάρχει ένας πολύ καλός τρόπος που σας επιτρέπει να εκτελέσετε το Tiller πολλές φορές σε ένα σύμπλεγμα. Δεν υπάρχει πρόβλημα με αυτό, το Tiller μπορεί να ξεκινήσει σε κάθε χώρο ονομάτων. Έτσι, μπορείτε να χρησιμοποιήσετε το RBAC, το Kubeconfig ως πλαίσιο και να περιορίσετε την πρόσβαση σε ένα ειδικό Helm.
Θα μοιάζει με αυτό.
Για παράδειγμα, υπάρχουν δύο Kubeconfig με περιβάλλον για διαφορετικές ομάδες (δύο χώροι ονομάτων): X Team για την ομάδα ανάπτυξης και το σύμπλεγμα διαχειριστή. Το σύμπλεγμα διαχειριστών έχει το δικό του ευρύ Tiller, το οποίο βρίσκεται στον χώρο ονομάτων του συστήματος Kube, έναν αντίστοιχα προηγμένο λογαριασμό υπηρεσίας. Και ένας ξεχωριστός χώρος ονομάτων για την ομάδα ανάπτυξης, θα μπορούν να αναπτύξουν τις υπηρεσίες τους σε έναν ειδικό χώρο ονομάτων.
Αυτή είναι μια εφαρμόσιμη προσέγγιση, ο Tiller δεν είναι τόσο πεινασμένος για δύναμη που θα επηρεάσει πολύ τον προϋπολογισμό σας. Αυτή είναι μια από τις γρήγορες λύσεις.
Μη διστάσετε να διαμορφώσετε το Tiller ξεχωριστά και να παρέχετε στο Kubeconfig πλαίσιο για την ομάδα, για έναν συγκεκριμένο προγραμματιστή ή για το περιβάλλον: Dev, Staging, Production (είναι αμφίβολο ότι όλα θα βρίσκονται στο ίδιο σύμπλεγμα, ωστόσο, αυτό μπορεί να γίνει).
Συνεχίζοντας την ιστορία μας, ας περάσουμε από το RBAC και ας μιλήσουμε για το ConfigMaps.
ConfigMaps
Η Helm χρησιμοποιεί το ConfigMaps ως χώρο αποθήκευσης δεδομένων. Όταν μιλήσαμε για αρχιτεκτονική, δεν υπήρχε πουθενά βάση δεδομένων που να αποθηκεύει πληροφορίες σχετικά με εκδόσεις, διαμορφώσεις, επαναλήψεις κ.λπ. Το ConfigMaps χρησιμοποιείται για αυτό.
Το κύριο πρόβλημα με τα ConfigMaps είναι γνωστό - δεν είναι ασφαλή κατ 'αρχήν. είναι αδύνατη η αποθήκευση ευαίσθητων δεδομένων. Μιλάμε για όλα όσα δεν πρέπει να υπερβαίνουν την υπηρεσία, για παράδειγμα, τους κωδικούς πρόσβασης. Ο πιο εγγενής τρόπος για το Helm αυτή τη στιγμή είναι να αλλάξει από τη χρήση ConfigMaps σε μυστικά.
Αυτό γίνεται πολύ απλά. Παρακάμψτε τη ρύθμιση Tiller και καθορίστε ότι η αποθήκευση θα είναι μυστική. Στη συνέχεια, για κάθε ανάπτυξη δεν θα λαμβάνετε ένα ConfigMap, αλλά ένα μυστικό.
Θα μπορούσατε να υποστηρίξετε ότι τα μυστικά από μόνα τους είναι μια περίεργη έννοια και όχι πολύ ασφαλής. Ωστόσο, αξίζει να καταλάβουμε ότι οι ίδιοι οι προγραμματιστές του Kubernetes το κάνουν αυτό. Ξεκινώντας από την έκδοση 1.10, δηλ. Εδώ και αρκετό καιρό, είναι δυνατό, τουλάχιστον στα δημόσια σύννεφα, να συνδεθεί ο σωστός χώρος αποθήκευσης για την αποθήκευση μυστικών. Η ομάδα εργάζεται τώρα για τρόπους καλύτερης διανομής της πρόσβασης σε μυστικά, μεμονωμένα pods ή άλλες οντότητες.
Είναι καλύτερα να μεταφέρετε το Storage Helm σε μυστικά και αυτά, με τη σειρά τους, ασφαλίζονται κεντρικά.
Φυσικά και θα παραμείνει όριο αποθήκευσης δεδομένων 1 MB. Το Helm εδώ χρησιμοποιεί etcd ως κατανεμημένο χώρο αποθήκευσης για ConfigMaps. Και εκεί θεώρησαν ότι αυτό ήταν ένα κατάλληλο κομμάτι δεδομένων για αναπαραγωγή κ.λπ. Υπάρχει μια ενδιαφέρουσα συζήτηση σχετικά με αυτό στο Reddit, προτείνω να βρείτε αυτό το αστείο διάβασμα για το Σαββατοκύριακο ή να διαβάσετε το απόσπασμα .
Chart Repos
Τα γραφήματα είναι τα πιο ευάλωτα κοινωνικά και μπορούν να γίνουν πηγή του "Άνθρωπος στη μέση", ειδικά εάν χρησιμοποιείτε μια λύση στοκ. Πρώτα απ 'όλα, μιλάμε για αποθετήρια που εκτίθενται μέσω HTTP.
Πρέπει οπωσδήποτε να εκθέσετε το Helm Repo μέσω HTTPS - αυτή είναι η καλύτερη επιλογή και είναι φθηνή.
Δώστε προσοχή μηχανισμός υπογραφής γραφήματος. Η τεχνολογία είναι απλή. Αυτό είναι το ίδιο πράγμα που χρησιμοποιείτε στο GitHub, ένα κανονικό μηχάνημα PGP με δημόσια και ιδιωτικά κλειδιά. Ρυθμίστε και βεβαιωθείτε, έχοντας τα απαραίτητα κλειδιά και υπογράφοντας τα πάντα, ότι αυτός είναι πραγματικά ο χάρτης σας.
Περαιτέρω, Ο πελάτης Helm υποστηρίζει TLS (όχι με την έννοια HTTP από την πλευρά του διακομιστή, αλλά αμοιβαίου TLS). Μπορείτε να χρησιμοποιήσετε κλειδιά διακομιστή και πελάτη για να επικοινωνήσετε. Για να είμαι ειλικρινής, δεν χρησιμοποιώ τέτοιο μηχανισμό γιατί δεν μου αρέσουν τα αμοιβαία πιστοποιητικά. Βασικα, - το κύριο εργαλείο για τη ρύθμιση του Helm Repo για το Helm 2 - υποστηρίζει επίσης τη βασική ταυτότητα. Μπορείτε να χρησιμοποιήσετε τη βασική πιστοποίηση εάν είναι πιο βολικό και πιο αθόρυβο.
Υπάρχει επίσης ένα πρόσθετο , το οποίο σας επιτρέπει να φιλοξενείτε Chart Repos στο Google Cloud Storage. Αυτό είναι αρκετά βολικό, λειτουργεί εξαιρετικά και είναι αρκετά ασφαλές, επειδή όλοι οι περιγραφόμενοι μηχανισμοί ανακυκλώνονται.
Εάν ενεργοποιήσετε το HTTPS ή το TLS, χρησιμοποιήσετε mTLS και ενεργοποιήσετε τη βασική εξουσιοδότηση για περαιτέρω μείωση των κινδύνων, θα έχετε ένα ασφαλές κανάλι επικοινωνίας με το Helm CLI και το Chart Repo.
gRPC API
Το επόμενο βήμα είναι πολύ σημαντικό - να ασφαλίσετε το Tiller, το οποίο βρίσκεται στο σύμπλεγμα και είναι, αφενός, ένας διακομιστής, αφετέρου, ο ίδιος έχει πρόσβαση σε άλλα στοιχεία και προσπαθεί να προσποιηθεί ότι είναι κάποιος.
Όπως είπα ήδη, το Tiller είναι μια υπηρεσία που εκθέτει το gRPC, ο πελάτης Helm έρχεται σε αυτήν μέσω gRPC. Από προεπιλογή, φυσικά, το TLS είναι απενεργοποιημένο. Το γιατί έγινε αυτό είναι μια αμφισβητήσιμη ερώτηση, μου φαίνεται ότι απλοποιώ τη ρύθμιση στην αρχή.
Για παραγωγή και ακόμη και σκηνοθεσία, προτείνω να ενεργοποιήσετε το TLS στο gRPC.
Κατά τη γνώμη μου, σε αντίθεση με το mTLS για γραφήματα, αυτό είναι κατάλληλο εδώ και γίνεται πολύ απλά - δημιουργήστε μια υποδομή PQI, δημιουργήστε ένα πιστοποιητικό, εκκινήστε το Tiller, μεταφέρετε το πιστοποιητικό κατά την προετοιμασία. Μετά από αυτό, μπορείτε να εκτελέσετε όλες τις εντολές Helm, παρουσιάζοντας τον εαυτό σας με το πιστοποιητικό που δημιουργήθηκε και το ιδιωτικό κλειδί.
Με αυτόν τον τρόπο θα προστατεύσετε τον εαυτό σας από όλα τα αιτήματα προς τον Tiller εκτός του συμπλέγματος.
Έτσι, έχουμε εξασφαλίσει το κανάλι σύνδεσης στο Tiller, έχουμε ήδη συζητήσει το RBAC και προσαρμόσαμε τα δικαιώματα του apiserver Kubernetes, μειώνοντας τον τομέα με τον οποίο μπορεί να αλληλεπιδράσει.
Προστατευμένο τιμόνι
Ας δούμε το τελικό διάγραμμα. Είναι η ίδια αρχιτεκτονική με τα ίδια βέλη.
Όλες οι συνδέσεις μπορούν πλέον να σχεδιαστούν με ασφάλεια με πράσινο χρώμα:
- για Chart Repo χρησιμοποιούμε TLS ή mTLS και βασικό έλεγχο ταυτότητας.
- mTLS για Tiller, και εκτίθεται ως υπηρεσία gRPC με TLS, χρησιμοποιούμε πιστοποιητικά.
- το σύμπλεγμα χρησιμοποιεί έναν ειδικό λογαριασμό υπηρεσίας με Role και RoleBinding.
Έχουμε εξασφαλίσει σημαντικά το σύμπλεγμα, αλλά κάποιος έξυπνος είπε:
«Μπορεί να υπάρξει μόνο μία απολύτως ασφαλής λύση - ένας κλειστός υπολογιστής, ο οποίος βρίσκεται σε ένα τσιμεντένιο κουτί και φυλάσσεται από στρατιώτες».
Υπάρχουν διάφοροι τρόποι χειρισμού δεδομένων και εύρεσης νέων φορέων επίθεσης. Ωστόσο, είμαι βέβαιος ότι αυτές οι συστάσεις θα επιτύχουν ένα βασικό βιομηχανικό πρότυπο ασφάλειας.
Δώρο
Αυτό το μέρος δεν σχετίζεται άμεσα με την ασφάλεια, αλλά θα είναι επίσης χρήσιμο. Θα σας δείξω μερικά ενδιαφέροντα πράγματα που λίγοι γνωρίζουν. Για παράδειγμα, πώς να αναζητήσετε γραφήματα - επίσημα και ανεπίσημα.
Στο αποθετήριο Τώρα υπάρχουν περίπου 300 διαγράμματα και δύο ροές: σταθερό και θερμοκοιτίδα. Όποιος συνεισφέρει γνωρίζει πολύ καλά πόσο δύσκολο είναι να φτάσεις από θερμοκοιτίδα σε στάβλο και πόσο εύκολο είναι να πετάξεις από το στάβλο. Ωστόσο, αυτό δεν είναι το καλύτερο εργαλείο για να αναζητήσετε γραφήματα για τον Prometheus και ό,τι άλλο θέλετε, για έναν απλό λόγο - δεν είναι μια πύλη όπου μπορείτε να αναζητήσετε βολικά πακέτα.
Αλλά υπάρχει μια υπηρεσία , γεγονός που καθιστά πολύ πιο βολικό την εύρεση γραφημάτων. Το πιο σημαντικό, υπάρχουν πολλά περισσότερα εξωτερικά αποθετήρια και σχεδόν 800 γούρια διαθέσιμα. Επιπλέον, μπορείτε να συνδέσετε το αποθετήριο σας εάν για κάποιο λόγο δεν θέλετε να στείλετε τα γραφήματα σας σε σταθερό.
Δοκιμάστε το hub.helm.sh και ας το αναπτύξουμε μαζί. Αυτή η υπηρεσία βρίσκεται στο πλαίσιο του έργου Helm και μπορείτε ακόμη και να συνεισφέρετε στη διεπαφή χρήστη της εάν είστε προγραμματιστής front-end και θέλετε απλώς να βελτιώσετε την εμφάνιση.
Θα ήθελα επίσης να επιστήσω την προσοχή σας Open Service Broker API ενσωμάτωσης. Ακούγεται δυσκίνητο και ασαφές, αλλά λύνει προβλήματα που αντιμετωπίζουν όλοι. Επιτρέψτε μου να εξηγήσω με ένα απλό παράδειγμα.
Υπάρχει ένα σύμπλεγμα Kubernetes στο οποίο θέλουμε να τρέξουμε μια κλασική εφαρμογή - το WordPress. Γενικά, απαιτείται μια βάση δεδομένων για πλήρη λειτουργικότητα. Υπάρχουν πολλές διαφορετικές λύσεις, για παράδειγμα, μπορείτε να ξεκινήσετε τη δική σας κρατική υπηρεσία. Αυτό δεν είναι πολύ βολικό, αλλά πολλοί άνθρωποι το κάνουν.
Άλλοι, όπως εμείς στο Chainstack, χρησιμοποιούν διαχειριζόμενες βάσεις δεδομένων όπως η MySQL ή η PostgreSQL για τους διακομιστές τους. Γι' αυτό οι βάσεις δεδομένων μας βρίσκονται κάπου στο σύννεφο.
Αλλά προκύπτει ένα πρόβλημα: πρέπει να συνδέσουμε την υπηρεσία μας με μια βάση δεδομένων, να δημιουργήσουμε μια γεύση βάσης δεδομένων, να μεταφέρουμε τα διαπιστευτήρια και με κάποιο τρόπο να τη διαχειριστούμε. Όλα αυτά γίνονται συνήθως χειροκίνητα από τον διαχειριστή ή τον προγραμματιστή του συστήματος. Και δεν υπάρχει πρόβλημα όταν υπάρχουν λίγες εφαρμογές. Όταν υπάρχουν πολλά, χρειάζεστε ένα συνδυασμό. Υπάρχει μια τέτοια θεριζοαλωνιστική μηχανή - είναι Service Broker. Σας επιτρέπει να χρησιμοποιείτε μια ειδική προσθήκη για ένα δημόσιο σύμπλεγμα cloud και να παραγγείλετε πόρους από τον πάροχο μέσω του Broker, σαν να ήταν ένα API. Για να το κάνετε αυτό, μπορείτε να χρησιμοποιήσετε εγγενή εργαλεία Kubernetes.
Είναι πολύ απλό. Μπορείτε να ρωτήσετε, για παράδειγμα, το Managed MySQL στο Azure με ένα βασικό επίπεδο (αυτό μπορεί να ρυθμιστεί). Χρησιμοποιώντας το Azure API, η βάση δεδομένων θα δημιουργηθεί και θα προετοιμαστεί για χρήση. Δεν χρειάζεται να παρέμβετε σε αυτό, το πρόσθετο είναι υπεύθυνο για αυτό. Για παράδειγμα, το OSBA (πρόσθετο Azure) θα επιστρέψει τα διαπιστευτήρια στην υπηρεσία και θα τα μεταβιβάσει στο Helm. Θα μπορείτε να χρησιμοποιείτε το WordPress με το cloud MySQL, να μην ασχολείστε καθόλου με διαχειριζόμενες βάσεις δεδομένων και να μην ανησυχείτε για κρατικές υπηρεσίες στο εσωτερικό.
Μπορούμε να πούμε ότι το Helm λειτουργεί ως κόλλα που, αφενός, σας επιτρέπει να αναπτύξετε υπηρεσίες και, αφετέρου, να καταναλώσετε τους πόρους των παρόχων cloud.
Μπορείτε να γράψετε το δικό σας πρόσθετο και να χρησιμοποιήσετε όλη αυτή την ιστορία on-premise. Τότε απλά θα έχετε το δικό σας πρόσθετο για τον εταιρικό πάροχο Cloud. Συνιστώ να δοκιμάσετε αυτήν την προσέγγιση, ειδικά εάν έχετε μεγάλη κλίμακα και θέλετε να αναπτύξετε γρήγορα την ανάπτυξη προγραμματισμού, τη σταδιοποίηση ή ολόκληρη την υποδομή για ένα χαρακτηριστικό. Αυτό θα διευκολύνει τη ζωή των λειτουργιών σας ή των DevOps.
Ένα άλλο εύρημα που ήδη ανέφερα είναι πρόσθετο helm-gcs, το οποίο σας επιτρέπει να χρησιμοποιείτε κουβάδες Google (αποθήκευση αντικειμένων) για την αποθήκευση γραφημάτων Helm.
Χρειάζεστε μόνο τέσσερις εντολές για να αρχίσετε να το χρησιμοποιείτε:
- εγκαταστήστε το πρόσθετο.
- ξεκινήστε το?
- ορίστε τη διαδρομή προς τον κάδο, ο οποίος βρίσκεται στο gcp.
- δημοσιεύουν γραφήματα με τον τυπικό τρόπο.
Η ομορφιά είναι ότι η εγγενής μέθοδος gcp θα χρησιμοποιηθεί για εξουσιοδότηση. Μπορείτε να χρησιμοποιήσετε έναν λογαριασμό υπηρεσίας, έναν λογαριασμό προγραμματιστή, ό,τι θέλετε. Είναι πολύ βολικό και δεν κοστίζει τίποτα για να λειτουργήσει. Εάν εσείς, όπως εγώ, προωθείτε τη φιλοσοφία των opsless, τότε αυτό θα είναι πολύ βολικό, ειδικά για μικρές ομάδες.
Εναλλακτικές λύσεις
Η Helm δεν είναι η μόνη λύση διαχείρισης υπηρεσιών. Υπάρχουν πολλά ερωτήματα σχετικά με αυτό, γι 'αυτό και η τρίτη έκδοση εμφανίστηκε τόσο γρήγορα. Φυσικά και υπάρχουν εναλλακτικές.
Αυτές μπορεί να είναι εξειδικευμένες λύσεις, για παράδειγμα, Ksonnet ή Metaparticle. Μπορείτε να χρησιμοποιήσετε τα κλασικά σας εργαλεία διαχείρισης υποδομής (Ansible, Terraform, Chef κ.λπ.) για τους ίδιους σκοπούς για τους οποίους μίλησα.
Επιτέλους υπάρχει λύση , του οποίου η δημοτικότητα αυξάνεται.
Το Operator Framework είναι η κορυφαία εναλλακτική λύση Helm που πρέπει να εξετάσετε.
Είναι πιο εγγενές στο CNCF και το Kubernetes, αλλά το εμπόδιο εισόδου είναι πολύ υψηλότερο, πρέπει να προγραμματίζετε περισσότερο και να περιγράφετε λιγότερο τις εκδηλώσεις.
Υπάρχουν διάφορα πρόσθετα, όπως Draft, Scaffold. Κάνουν τη ζωή πολύ πιο εύκολη, για παράδειγμα, απλοποιούν τον κύκλο αποστολής και εκκίνησης του Helm ώστε οι προγραμματιστές να αναπτύξουν ένα δοκιμαστικό περιβάλλον. Θα τους έλεγα εξουσιοδοτημένους.
Εδώ είναι ένα οπτικό διάγραμμα όπου βρίσκονται τα πάντα.
Στον άξονα x είναι το επίπεδο του προσωπικού σας ελέγχου για το τι συμβαίνει, στον άξονα y είναι το επίπεδο της εγγενότητας του Kubernetes. Η έκδοση Helm 2 πέφτει κάπου στη μέση. Στην έκδοση 3, όχι πολύ, αλλά τόσο ο έλεγχος όσο και το επίπεδο εγγενότητας έχουν βελτιωθεί. Οι λύσεις σε επίπεδο Ksonnet εξακολουθούν να είναι κατώτερες ακόμη και από το Helm 2. Ωστόσο, αξίζει να τις εξετάσετε για να μάθετε τι άλλο υπάρχει σε αυτόν τον κόσμο. Φυσικά, ο διαχειριστής διαμόρφωσης θα είναι υπό τον έλεγχό σας, αλλά δεν είναι απολύτως εγγενής στο Kubernetes.
Το Operator Framework είναι απολύτως εγγενές στο Kubernetes και σας επιτρέπει να το διαχειρίζεστε πολύ πιο κομψά και σχολαστικά (αλλά να θυμάστε το αρχικό επίπεδο). Μάλλον, αυτό είναι κατάλληλο για μια εξειδικευμένη εφαρμογή και τη δημιουργία διαχείρισης για αυτήν, παρά για μια μαζική συγκομιδή για τη συσκευασία ενός τεράστιου αριθμού εφαρμογών χρησιμοποιώντας το Helm.
Οι επεκτάσεις απλώς βελτιώνουν λίγο τον έλεγχο, συμπληρώνουν τη ροή εργασίας ή κόβουν γωνίες σε αγωγούς CI/CD.
Το μέλλον του Helm
Τα καλά νέα είναι ότι έρχεται το Helm 3. Η alpha έκδοση του Helm 3.0.0-alpha.2 έχει ήδη κυκλοφορήσει, μπορείτε να το δοκιμάσετε. Είναι αρκετά σταθερό, αλλά η λειτουργικότητα εξακολουθεί να είναι περιορισμένη.
Γιατί χρειάζεστε το Helm 3; Πρώτα απ 'όλα, πρόκειται για μια ιστορία εξαφάνιση του Τίλερ, ως συστατικό. Αυτό, όπως ήδη καταλαβαίνετε, είναι ένα τεράστιο βήμα προς τα εμπρός, γιατί από την άποψη της ασφάλειας της αρχιτεκτονικής, όλα είναι απλοποιημένα.
Όταν δημιουργήθηκε το Helm 2, το οποίο ήταν περίπου την εποχή του Kubernetes 1.8 ή και παλαιότερα, πολλές από τις έννοιες ήταν ανώριμες. Για παράδειγμα, η ιδέα CRD εφαρμόζεται τώρα ενεργά και η Helm θα το κάνει χρησιμοποιήστε CRDγια την αποθήκευση κατασκευών. Θα είναι δυνατή η χρήση μόνο του πελάτη και όχι η συντήρηση του τμήματος διακομιστή. Αντίστοιχα, χρησιμοποιήστε εγγενείς εντολές Kubernetes για να εργαστείτε με δομές και πόρους. Αυτό είναι ένα τεράστιο βήμα προς τα εμπρός.
Θα εμφανιστει υποστήριξη για εγγενείς αποθήκες OCI (Πρωτοβουλία Open Container). Αυτή είναι μια τεράστια πρωτοβουλία, και η Helm ενδιαφέρεται πρωτίστως για να δημοσιεύσει τα τσαρτ της. Φτάνει στο σημείο ότι, για παράδειγμα, το Docker Hub υποστηρίζει πολλά πρότυπα OCI. Δεν φαντάζομαι, αλλά ίσως οι κλασικοί πάροχοι αποθετηρίων Docker θα αρχίσουν να σας δίνουν την ευκαιρία να φιλοξενήσετε τα γραφήματα Helm σας.
Η αμφιλεγόμενη ιστορία για μένα είναι Υποστήριξη Lua, ως μηχανή προτύπων για τη σύνταξη σεναρίων. Δεν είμαι μεγάλος θαυμαστής του Lua, αλλά αυτό θα ήταν ένα εντελώς προαιρετικό χαρακτηριστικό. Το έλεγξα αυτό 3 φορές - η χρήση του Lua δεν θα είναι απαραίτητη. Επομένως, όσοι θέλουν να μπορούν να χρησιμοποιούν το Lua, όσοι τους αρέσει το Go, μπαίνουν στο τεράστιο στρατόπεδό μας και χρησιμοποιούν το go-tmpl για αυτό.
Τελικά, αυτό που μου έλειπε σίγουρα ήταν εμφάνιση σχήματος και επικύρωση τύπου δεδομένων. Δεν θα υπάρχουν άλλα προβλήματα με το int ή τη συμβολοσειρά, δεν χρειάζεται να τυλίξετε το μηδέν σε διπλά εισαγωγικά. Θα εμφανιστεί ένα σχήμα JSONS που θα σας επιτρέψει να το περιγράψετε ρητά για τις τιμές.
Θα υποβληθεί σε μεγάλη επεξεργασία μοντέλο που βασίζεται σε εκδηλώσεις. Έχει ήδη περιγραφεί εννοιολογικά. Κοιτάξτε τον κλάδο Helm 3 και θα δείτε πόσα συμβάντα, άγκιστρα και άλλα πράγματα έχουν προστεθεί, κάτι που θα απλοποιήσει πολύ και, από την άλλη πλευρά, θα προσθέσει έλεγχο στις διαδικασίες ανάπτυξης και τις αντιδράσεις σε αυτά.
Το Helm 3 θα είναι πιο απλό, πιο ασφαλές και πιο διασκεδαστικό, όχι επειδή δεν μας αρέσει το Helm 2, αλλά επειδή το Kubernetes γίνεται πιο προηγμένο. Αντίστοιχα, η Helm μπορεί να χρησιμοποιήσει τις εξελίξεις του Kubernetes και να δημιουργήσει εξαιρετικούς διαχειριστές για την Kubernetes σε αυτό.
Ένα άλλο καλό νέο είναι αυτό Ο Alexander Khayorov θα σας πει, Να σας υπενθυμίσουμε ότι το συνέδριο για την ενοποίηση των διαδικασιών ανάπτυξης, δοκιμών και λειτουργίας θα πραγματοποιηθεί στη Μόσχα 30 Σεπτεμβρίου και 1 Οκτωβρίου. Μπορείτε ακόμα να το κάνετε μέχρι τις 20 Αυγούστου και πείτε μας για την εμπειρία σας με τη λύση καθήκοντα της προσέγγισης DevOps.
Ακολουθήστε σημεία ελέγχου συνεδρίων και ειδήσεις στο и .
Πηγή: www.habr.com