Σημείωση. μετάφρ.: Σας παρουσιάζουμε τη μετάφραση ενός άρθρου από ανώτερο μηχανικό ασφαλείας εφαρμογών στη βρετανική εταιρεία ASOS.com. Με αυτό, ξεκινά μια σειρά από δημοσιεύσεις αφιερωμένες στη βελτίωση της ασφάλειας στο Kubernetes μέσω της χρήσης του seccomp. Αν αρέσει στους αναγνώστες η εισαγωγή, θα ακολουθήσουμε τον συγγραφέα και θα συνεχίσουμε με το μελλοντικό του υλικό για αυτό το θέμα.
Αυτό το άρθρο είναι το πρώτο σε μια σειρά αναρτήσεων για το πώς να δημιουργείτε προφίλ seccomp στο πνεύμα του SecDevOps, χωρίς να καταφεύγετε σε μαγεία και μαγεία. Στο Μέρος XNUMX, θα καλύψω τα βασικά και τις εσωτερικές λεπτομέρειες της εφαρμογής του seccomp στο Kubernetes.
Το οικοσύστημα Kubernetes προσφέρει μια μεγάλη ποικιλία τρόπων ασφάλισης και απομόνωσης δοχείων. Το άρθρο αφορά την ασφαλή λειτουργία υπολογισμού, γνωστή και ως σεξ. Η ουσία του είναι να φιλτράρει τις κλήσεις συστήματος που είναι διαθέσιμες για εκτέλεση από κοντέινερ.
Γιατί είναι σημαντικό? Ένα δοχείο είναι απλώς μια διαδικασία που εκτελείται σε ένα συγκεκριμένο μηχάνημα. Και χρησιμοποιεί τον πυρήνα όπως και άλλες εφαρμογές. Εάν τα κοντέινερ μπορούσαν να πραγματοποιήσουν οποιεσδήποτε κλήσεις συστήματος, πολύ σύντομα το κακόβουλο λογισμικό θα το εκμεταλλευόταν για να παρακάμψει την απομόνωση κοντέινερ και να επηρεάσει άλλες εφαρμογές: υποκλοπή πληροφοριών, αλλαγή ρυθμίσεων συστήματος κ.λπ.
Τα προφίλ seccomp καθορίζουν ποιες κλήσεις συστήματος πρέπει να επιτρέπονται ή να απενεργοποιούνται. Ο χρόνος εκτέλεσης του κοντέινερ τα ενεργοποιεί όταν ξεκινά, έτσι ώστε ο πυρήνας να παρακολουθεί την εκτέλεσή τους. Η χρήση τέτοιων προφίλ σάς επιτρέπει να περιορίσετε το διάνυσμα επίθεσης και να μειώσετε τη ζημιά εάν οποιοδήποτε πρόγραμμα μέσα στο κοντέινερ (δηλαδή οι εξαρτήσεις σας ή οι εξαρτήσεις τους) αρχίσει να κάνει κάτι που δεν επιτρέπεται να κάνει.
Φτάνοντας στα βασικά
Το βασικό προφίλ seccomp περιλαμβάνει τρία στοιχεία: defaultAction, architectures (ή archMap) Και syscalls:
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"arch_prctl",
"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp"
],
"action": "SCMP_ACT_ALLOW"
}
]
}()
defaultAction καθορίζει την προεπιλεγμένη τύχη οποιασδήποτε κλήσης συστήματος που δεν προσδιορίζεται στην ενότητα syscalls. Για να κάνουμε τα πράγματα πιο εύκολα, ας εστιάσουμε στις δύο κύριες τιμές που θα χρησιμοποιηθούν:
-
SCMP_ACT_ERRNO— αποκλείει την εκτέλεση μιας κλήσης συστήματος, -
SCMP_ACT_ALLOW- επιτρέπει.
Στο τμήμα architectures παρατίθενται αρχιτεκτονικές στόχου. Αυτό είναι σημαντικό επειδή το ίδιο το φίλτρο, που εφαρμόζεται σε επίπεδο πυρήνα, εξαρτάται από τα αναγνωριστικά κλήσεων συστήματος και όχι από τα ονόματά τους που καθορίζονται στο προφίλ. Ο χρόνος εκτέλεσης του κοντέινερ θα τα ταιριάξει με τα αναγνωριστικά πριν από τη χρήση. Η ιδέα είναι ότι οι κλήσεις συστήματος μπορούν να έχουν εντελώς διαφορετικά αναγνωριστικά ανάλογα με την αρχιτεκτονική του συστήματος. Για παράδειγμα, κλήση συστήματος recvfrom (χρησιμοποιείται για τη λήψη πληροφοριών από την υποδοχή) έχει ID = 64 σε συστήματα x64 και ID = 517 σε x86. μπορείτε να βρείτε μια λίστα με όλες τις κλήσεις συστήματος για αρχιτεκτονικές x86-x64.
Στην ενότητα syscalls παραθέτει όλες τις κλήσεις συστήματος και καθορίζει τι να κάνετε με αυτές. Για παράδειγμα, μπορείτε να δημιουργήσετε μια λίστα επιτρεπόμενων ορίζοντας defaultAction επί SCMP_ACT_ERRNO, και κλήσεις στην ενότητα syscalls κατάλληλος SCMP_ACT_ALLOW. Επομένως, επιτρέπετε μόνο τις κλήσεις που καθορίζονται στην ενότητα syscallsκαι να απαγορεύσει όλα τα άλλα. Για τη μαύρη λίστα θα πρέπει να αλλάξετε τις τιμές defaultAction και ενέργειες προς το αντίθετο.
Τώρα πρέπει να πούμε λίγα λόγια για αποχρώσεις που δεν είναι τόσο προφανείς. Λάβετε υπόψη ότι οι παρακάτω προτάσεις προϋποθέτουν ότι αναπτύσσετε μια σειρά επιχειρηματικών εφαρμογών στο Kubernetes και θέλετε να εκτελούνται με τον ελάχιστο δυνατό αριθμό προνομίων.
1. AllowPrivilegeEscalation=false
В securityContext Το δοχείο έχει μια παράμετρο AllowPrivilegeEscalation. Εάν είναι εγκατεστημένο σε false, τα δοχεία θα ξεκινούν με (on) λίγο . Το νόημα αυτής της παραμέτρου είναι προφανές από το όνομα: εμποδίζει το κοντέινερ να ξεκινήσει νέες διεργασίες με περισσότερα προνόμια από αυτά που έχει το ίδιο.
Μια παρενέργεια αυτής της επιλογής που έχει οριστεί σε true (προεπιλογή) είναι ότι ο χρόνος εκτέλεσης του κοντέινερ εφαρμόζει το προφίλ seccomp στην αρχή της διαδικασίας εκκίνησης. Έτσι, όλες οι κλήσεις συστήματος που απαιτούνται για την εκτέλεση εσωτερικών διεργασιών χρόνου εκτέλεσης (π.χ. ρύθμιση αναγνωριστικών χρηστών/ομάδων, απόρριψη ορισμένων δυνατοτήτων) πρέπει να είναι ενεργοποιημένες στο προφίλ.
Σε ένα δοχείο που κάνει ασήμαντα πράγματα echo hi, θα απαιτηθούν τα ακόλουθα δικαιώματα:
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"arch_prctl",
"brk",
"capget",
"capset",
"chdir",
"close",
"execve",
"exit_group",
"fstat",
"fstatfs",
"futex",
"getdents64",
"getppid",
"lstat",
"mprotect",
"nanosleep",
"newfstatat",
"openat",
"prctl",
"read",
"rt_sigaction",
"statfs",
"setgid",
"setgroups",
"setuid",
"stat",
"uname",
"write"
],
"action": "SCMP_ACT_ALLOW"
}
]
}()
...αντί για αυτά:
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"arch_prctl",
"brk",
"close",
"execve",
"exit_group",
"futex",
"mprotect",
"nanosleep",
"stat",
"write"
],
"action": "SCMP_ACT_ALLOW"
}
]
}()
Αλλά και πάλι, γιατί είναι αυτό ένα πρόβλημα; Προσωπικά, θα απέφευγα να βάλω στη λίστα επιτρεπόμενων τις ακόλουθες κλήσεις συστήματος (εκτός αν υπάρχει πραγματική ανάγκη για αυτές): capset, set_tid_address, setgid, setgroups и setuid. Ωστόσο, η πραγματική πρόκληση είναι ότι επιτρέποντας διεργασίες που δεν έχετε κανέναν απολύτως έλεγχο, συνδέετε τα προφίλ με την υλοποίηση χρόνου εκτέλεσης κοντέινερ. Με άλλα λόγια, μια μέρα μπορεί να διαπιστώσετε ότι μετά την ενημέρωση του περιβάλλοντος χρόνου εκτέλεσης κοντέινερ (είτε από εσάς είτε, πιθανότατα, από τον πάροχο υπηρεσιών cloud), τα κοντέινερ σταματούν ξαφνικά να λειτουργούν.
Συμβουλή # 1: Εκτελέστε δοχεία με AllowPrivilegeEscaltion=false. Αυτό θα μειώσει το μέγεθος των προφίλ seccomp και θα τα καταστήσει λιγότερο ευαίσθητα στις αλλαγές στο περιβάλλον χρόνου εκτέλεσης κοντέινερ.
2. Ρύθμιση προφίλ seccomp στο επίπεδο του κοντέινερ
Το προφίλ seccomp μπορεί να οριστεί σε επίπεδο pod:
annotations:
seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"...ή σε επίπεδο δοχείου:
annotations:
container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"Λάβετε υπόψη ότι η παραπάνω σύνταξη θα αλλάξει όταν το Kubernetes seccomp (αυτό το συμβάν αναμένεται στην επόμενη κυκλοφορία του Kubernetes - 1.18 - περ. μετάφρ.).
Λίγοι γνωρίζουν ότι το Kubernetes είχε πάντα που προκάλεσε την εφαρμογή προφίλ seccomp . Το περιβάλλον εκτέλεσης αντισταθμίζει εν μέρει αυτήν την έλλειψη, αλλά αυτό το κοντέινερ δεν εξαφανίζεται από τα pods, καθώς χρησιμοποιείται για τη διαμόρφωση της υποδομής τους.
Το πρόβλημα είναι ότι αυτό το δοχείο ξεκινά πάντα με AllowPrivilegeEscalation=true, που οδηγεί στα προβλήματα που εκφράζονται στην παράγραφο 1, και αυτό δεν μπορεί να αλλάξει.
Χρησιμοποιώντας προφίλ seccomp σε επίπεδο κοντέινερ, αποφεύγετε αυτήν την παγίδα και μπορείτε να δημιουργήσετε ένα προφίλ που είναι προσαρμοσμένο σε ένα συγκεκριμένο κοντέινερ. Αυτό θα πρέπει να γίνει έως ότου οι προγραμματιστές διορθώσουν το σφάλμα και η νέα έκδοση (ίσως 1.18;) γίνει διαθέσιμη σε όλους.
Συμβουλή # 2: Ορίστε τα προφίλ seccomp στο επίπεδο του κοντέινερ.
Από πρακτική άποψη, αυτός ο κανόνας χρησιμεύει συνήθως ως μια καθολική απάντηση στην ερώτηση: «Γιατί λειτουργεί το προφίλ μου seccomp με docker runαλλά δεν λειτουργεί μετά την ανάπτυξη σε ένα σύμπλεγμα Kubernetes;
3. Χρησιμοποιήστε το χρόνο εκτέλεσης/προεπιλογή μόνο ως έσχατη λύση
Το Kubernetes έχει δύο επιλογές για ενσωματωμένα προφίλ: runtime/default и docker/default. Και τα δύο υλοποιούνται από το χρόνο εκτέλεσης του κοντέινερ, όχι από το Kubernetes. Επομένως, ενδέχεται να διαφέρουν ανάλογα με το περιβάλλον χρόνου εκτέλεσης που χρησιμοποιείται και την έκδοσή του.
Με άλλα λόγια, ως αποτέλεσμα της αλλαγής του χρόνου εκτέλεσης, το κοντέινερ μπορεί να έχει πρόσβαση σε ένα διαφορετικό σύνολο κλήσεων συστήματος, τις οποίες μπορεί να χρησιμοποιήσει ή όχι. Οι περισσότεροι χρόνοι εκτέλεσης χρησιμοποιούν . Εάν θέλετε να χρησιμοποιήσετε αυτό το προφίλ, βεβαιωθείτε ότι είναι κατάλληλο για εσάς.
Προφίλ docker/default έχει καταργηθεί από το Kubernetes 1.11, επομένως αποφύγετε τη χρήση του.
Κατά τη γνώμη μου, προφίλ runtime/default είναι απόλυτα κατάλληλο για το σκοπό για τον οποίο δημιουργήθηκε: προστασία των χρηστών από τους κινδύνους που σχετίζονται με την εκτέλεση μιας εντολής docker run στα αυτοκίνητά τους. Ωστόσο, όταν πρόκειται για επιχειρηματικές εφαρμογές που εκτελούνται σε συμπλέγματα Kubernetes, θα τολμούσα να υποστηρίξω ότι ένα τέτοιο προφίλ είναι πολύ ανοιχτό και οι προγραμματιστές πρέπει να επικεντρωθούν στη δημιουργία προφίλ για τις εφαρμογές τους (ή τύπους εφαρμογών).
Συμβουλή # 3: Δημιουργήστε προφίλ seccomp για συγκεκριμένες εφαρμογές. Εάν αυτό δεν είναι δυνατό, δημιουργήστε προφίλ για τύπους εφαρμογών, για παράδειγμα, δημιουργήστε ένα σύνθετο προφίλ που περιλαμβάνει όλα τα web API της εφαρμογής Golang. Χρησιμοποιήστε μόνο χρόνο εκτέλεσης/προεπιλογή ως έσχατη λύση.
Σε μελλοντικές αναρτήσεις, θα καλύψω πώς να δημιουργήσετε προφίλ seccomp εμπνευσμένα από το SecDevOps, να τα αυτοματοποιήσετε και να τα δοκιμάσετε σε αγωγούς. Με άλλα λόγια, δεν θα έχετε καμία δικαιολογία για να μην κάνετε αναβάθμιση σε προφίλ για συγκεκριμένες εφαρμογές.
4. Το Unconfined ΔΕΝ αποτελεί επιλογή.
από αποδείχθηκε ότι από προεπιλογή . Αυτό σημαίνει ότι αν δεν ορίσετε PodSecurityPolicy, το οποίο θα το ενεργοποιήσει στο σύμπλεγμα, όλα τα pod για τα οποία δεν έχει οριστεί το προφίλ seccomp θα λειτουργούν σε seccomp=unconfined.
Η λειτουργία σε αυτή τη λειτουργία σημαίνει ότι χάνεται ένα ολόκληρο στρώμα μόνωσης που προστατεύει το σύμπλεγμα. Αυτή η προσέγγιση δεν συνιστάται από ειδικούς σε θέματα ασφάλειας.
Συμβουλή # 4: Δεν πρέπει να τρέχει κανένα κοντέινερ στο σύμπλεγμα seccomp=unconfined, ειδικά σε περιβάλλοντα παραγωγής.
5. "Λειτουργία ελέγχου"
Αυτό το σημείο δεν είναι μοναδικό για το Kubernetes, αλλά εξακολουθεί να εμπίπτει στην κατηγορία "πράγματα που πρέπει να γνωρίζετε πριν ξεκινήσετε".
Όπως συμβαίνει, η δημιουργία προφίλ seccomp ήταν πάντα προκλητική και βασίζεται σε μεγάλο βαθμό στη δοκιμή και το σφάλμα. Γεγονός είναι ότι οι χρήστες απλά δεν έχουν την ευκαιρία να τους δοκιμάσουν σε περιβάλλοντα παραγωγής χωρίς να διακινδυνεύσουν να «πέσουν» η εφαρμογή.
Μετά την κυκλοφορία του πυρήνα Linux 4.14, κατέστη δυνατή η εκτέλεση τμημάτων ενός προφίλ σε λειτουργία ελέγχου, καταγράφοντας πληροφορίες για όλες τις κλήσεις συστήματος στο syslog, αλλά χωρίς να τις αποκλείσετε. Μπορείτε να ενεργοποιήσετε αυτήν τη λειτουργία χρησιμοποιώντας την παράμετρο SCMT_ACT_LOG:
SCMP_ACT_LOG: Το seccomp δεν θα επηρεάσει το νήμα που πραγματοποιεί την κλήση συστήματος εάν δεν ταιριάζει με κανέναν κανόνα στο φίλτρο, αλλά θα καταγράφονται πληροφορίες σχετικά με την κλήση συστήματος.
Ακολουθεί μια τυπική στρατηγική για τη χρήση αυτής της δυνατότητας:
- Επιτρέψτε τις κλήσεις συστήματος που απαιτούνται.
- Αποκλείστε κλήσεις από το σύστημα που γνωρίζετε ότι δεν θα είναι χρήσιμες.
- Καταγράψτε πληροφορίες για όλες τις άλλες κλήσεις στο αρχείο καταγραφής.
Ένα απλοποιημένο παράδειγμα μοιάζει με αυτό:
{
"defaultAction": "SCMP_ACT_LOG",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"arch_prctl",
"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp"
],
"action": "SCMP_ACT_ALLOW"
},
{
"names": [
"add_key",
"keyctl",
"ptrace"
],
"action": "SCMP_ACT_ERRNO"
}
]
}()
Αλλά να θυμάστε ότι πρέπει να αποκλείσετε όλες τις κλήσεις που γνωρίζετε ότι δεν θα χρησιμοποιηθούν και που θα μπορούσαν ενδεχομένως να βλάψουν το σύμπλεγμα. Μια καλή βάση για τη σύνταξη μιας λίστας είναι η επίσημη . Εξηγεί λεπτομερώς ποιες κλήσεις συστήματος είναι αποκλεισμένες στο προεπιλεγμένο προφίλ και γιατί.
Ωστόσο, υπάρχει ένα πιάσιμο. Αν και SCMT_ACT_LOG που υποστηρίζεται από τον πυρήνα Linux από τα τέλη του 2017, μπήκε στο οικοσύστημα Kubernetes μόλις σχετικά πρόσφατα. Επομένως, για να χρησιμοποιήσετε αυτήν τη μέθοδο θα χρειαστείτε έναν πυρήνα Linux 4.14 και έκδοση runC όχι χαμηλότερη .
Συμβουλή # 5: Μπορεί να δημιουργηθεί ένα προφίλ λειτουργίας ελέγχου για δοκιμή στην παραγωγή συνδυάζοντας ασπρόμαυρες λίστες και μπορούν να καταγραφούν όλες οι εξαιρέσεις.
6. Χρησιμοποιήστε λευκές λίστες
Η προσθήκη στη λίστα επιτρεπόμενων απαιτεί πρόσθετη προσπάθεια, επειδή πρέπει να προσδιορίσετε κάθε κλήση που μπορεί να χρειαστεί η εφαρμογή, αλλά αυτή η προσέγγιση βελτιώνει σημαντικά την ασφάλεια:
Συνιστάται ιδιαίτερα η χρήση της προσέγγισης της λευκής λίστας καθώς είναι απλούστερη και πιο αξιόπιστη. Η μαύρη λίστα θα πρέπει να ενημερώνεται κάθε φορά που προστίθεται μια δυνητικά επικίνδυνη κλήση συστήματος (ή μια επικίνδυνη σημαία/επιλογή εάν βρίσκεται στη μαύρη λίστα). Επιπλέον, είναι συχνά δυνατή η αλλαγή της αναπαράστασης μιας παραμέτρου χωρίς αλλαγή της ουσίας της και, επομένως, η παράκαμψη των περιορισμών της μαύρης λίστας.
Για τις εφαρμογές Go, ανέπτυξα ένα ειδικό εργαλείο που συνοδεύει την εφαρμογή και συλλέγει όλες τις κλήσεις που γίνονται κατά την εκτέλεση. Για παράδειγμα, για την ακόλουθη εφαρμογή:
package main
import "fmt"
func main() {
fmt.Println("test")
}
... ας ξεκινήσουμε gosystract όπως αυτό:
go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path... και έχουμε το εξής αποτέλεσμα:
"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",Προς το παρόν, αυτό είναι μόνο ένα παράδειγμα—θα ακολουθήσουν περισσότερες λεπτομέρειες σχετικά με τα εργαλεία.
Συμβουλή # 6: Επιτρέψτε μόνο εκείνες τις κλήσεις που πραγματικά χρειάζεστε και αποκλείστε όλες τις άλλες.
7. Βάλτε τις σωστές βάσεις (ή προετοιμαστείτε για απροσδόκητη συμπεριφορά)
Ο πυρήνας θα επιβάλει το προφίλ ανεξάρτητα από το τι γράφετε σε αυτό. Ακόμα κι αν δεν είναι ακριβώς αυτό που ήθελες. Για παράδειγμα, εάν αποκλείσετε την πρόσβαση σε κλήσεις όπως exit ή exit_group, το κοντέινερ δεν θα μπορεί να κλείσει σωστά και ακόμη και μια απλή εντολή όπως echo hi o για αόριστο χρονικό διάστημα. Ως αποτέλεσμα, θα έχετε υψηλή χρήση CPU στο σύμπλεγμα:
Σε τέτοιες περιπτώσεις, ένα βοηθητικό πρόγραμμα μπορεί να έρθει στη διάσωση strace - θα δείξει ποιο μπορεί να είναι το πρόβλημα:
sudo strace -c -p 9331
Βεβαιωθείτε ότι τα προφίλ περιέχουν όλες τις κλήσεις συστήματος που χρειάζεται η εφαρμογή κατά το χρόνο εκτέλεσης.
Συμβουλή # 7: Δώστε προσοχή στη λεπτομέρεια και βεβαιωθείτε ότι όλες οι απαραίτητες κλήσεις συστήματος βρίσκονται στη λίστα επιτρεπόμενων.
Αυτό ολοκληρώνει το πρώτο μέρος μιας σειράς άρθρων σχετικά με τη χρήση του seccomp στο Kubernetes στο πνεύμα του SecDevOps. Στα επόμενα μέρη θα μιλήσουμε για το γιατί αυτό είναι σημαντικό και πώς να αυτοματοποιήσετε τη διαδικασία.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «"?
- «».
Πηγή: www.habr.com