Εισαγωγή στις πολιτικές δικτύου Kubernetes για επαγγελματίες ασφαλείας

Σημείωση. μετάφρ.: Ο συγγραφέας του άρθρου, Reuven Harrison, έχει πάνω από 20 χρόνια εμπειρίας στην ανάπτυξη λογισμικού και σήμερα είναι ο CTO και συνιδρυτής της Tufin, μιας εταιρείας που δημιουργεί λύσεις διαχείρισης πολιτικής ασφάλειας. Ενώ βλέπει τις πολιτικές δικτύου Kubernetes ως ένα αρκετά ισχυρό εργαλείο για την τμηματοποίηση δικτύου σε ένα σύμπλεγμα, πιστεύει επίσης ότι δεν είναι τόσο εύκολο να εφαρμοστούν στην πράξη. Αυτό το υλικό (αρκετά ογκώδες) προορίζεται να βελτιώσει την επίγνωση των ειδικών για αυτό το ζήτημα και να τους βοηθήσει να δημιουργήσουν τις απαραίτητες διαμορφώσεις.

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

Για τους επαγγελματίες ασφαλείας που μπερδεύονται με την εργασία με την Kubernetes, η πραγματική αποκάλυψη μπορεί να είναι η προεπιλεγμένη πολιτική της πλατφόρμας: επιτρέψτε τα πάντα.

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

Πολιτικές δικτύου Kubernetes

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

Οι πολιτικές δικτύου ελέγχουν τις επικοινωνίες μεταξύ των pods

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

Καθορισμός πολιτικών δικτύου

Όπως και άλλοι πόροι Kubernetes, οι πολιτικές δικτύου καθορίζονται στο YAML. Στο παρακάτω παράδειγμα, η εφαρμογή balance πρόσβαση σε postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(Σημείωση. μετάφρ.: αυτό το στιγμιότυπο οθόνης, όπως όλα τα επόμενα παρόμοια, δημιουργήθηκε όχι χρησιμοποιώντας εγγενή εργαλεία Kubernetes, αλλά χρησιμοποιώντας το εργαλείο Tufin Orca, το οποίο αναπτύχθηκε από την εταιρεία του συγγραφέα του αρχικού άρθρου και το οποίο αναφέρεται στο τέλος του υλικού.)

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

Έχοντας περιγράψει την πολιτική στο YAML, χρησιμοποιήστε kubectlγια να το δημιουργήσετε στο σύμπλεγμα:

kubectl create -f policy.yaml

Προδιαγραφή πολιτικής δικτύου

Η προδιαγραφή πολιτικής δικτύου Kubernetes περιλαμβάνει τέσσερα στοιχεία:

1. podSelector: ορίζει τις ομάδες που επηρεάζονται από αυτήν την πολιτική (στόχοι) - απαιτείται.
2. policyTypes: υποδεικνύει τους τύπους πολιτικών που περιλαμβάνονται σε αυτό: είσοδος και/ή έξοδος - προαιρετική, αλλά συνιστώ να το προσδιορίσετε ρητά σε όλες τις περιπτώσεις.
3. ingress: ορίζει επιτρεπόμενο εισερχόμενα κυκλοφορία σε ομάδες στόχων - προαιρετική.
4. egress: ορίζει επιτρεπόμενο εξερχόμενος Η επισκεψιμότητα από ομάδες προορισμού είναι προαιρετική.

Παράδειγμα από τον ιστότοπο της Kubernetes (αντικατέστησα role επί app), δείχνει πώς χρησιμοποιούνται και τα τέσσερα στοιχεία:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Λάβετε υπόψη ότι και τα τέσσερα στοιχεία δεν χρειάζεται να συμπεριληφθούν. Είναι μόνο υποχρεωτικό podSelector, άλλες παράμετροι μπορούν να χρησιμοποιηθούν όπως επιθυμείτε.

Αν παραλείψετε policyTypes, η πολιτική θα ερμηνευτεί ως εξής:

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

Για αποφυγή λαθών προτείνω να το κάνετε πάντα σαφές policyTypes.

Σύμφωνα με την παραπάνω λογική, αν οι παράμετροι ingress και / ή egress Εάν παραλειφθεί, η πολιτική θα απορρίψει όλη την επισκεψιμότητα (βλ. "Κανόνας απογύμνωσης" παρακάτω).

Η προεπιλεγμένη πολιτική είναι Να επιτρέπεται

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

Χώροι ονομάτων

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

Όπως τα περισσότερα στοιχεία του Kubernetes, οι πολιτικές δικτύου ζουν σε συγκεκριμένο χώρο ονομάτων. Στο μπλοκ metadata μπορείτε να καθορίσετε σε ποιο χώρο ανήκει η πολιτική:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Εάν ο χώρος ονομάτων δεν καθορίζεται ρητά στα μεταδεδομένα, το σύστημα θα χρησιμοποιήσει τον χώρο ονομάτων που καθορίζεται στο kubectl (από προεπιλογή namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

προτείνω προσδιορίστε ρητά τον χώρο ονομάτων, εκτός εάν συντάσσετε μια πολιτική που στοχεύει πολλούς χώρους ονομάτων ταυτόχρονα.

Πρωταρχικός στοιχείο podSelector στην πολιτική θα επιλέξει ομάδες από τον χώρο ονομάτων στον οποίο ανήκει η πολιτική (δεν επιτρέπεται η πρόσβαση σε ομάδες από άλλο χώρο ονομάτων).

Ομοίως, podSelectors στα μπλοκ εισόδου και εξόδου μπορούν να επιλέξουν μόνο ομάδες από το δικό τους χώρο ονομάτων, εκτός φυσικά και αν τις συνδυάσετε namespaceSelector (αυτό θα συζητηθεί στην ενότητα «Φιλτράρισμα κατά χώρους ονομάτων και λοβούς»).

Κανόνες ονομασίας πολιτικής

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

Μου αρέσει ιδιαίτερα μια από τις μεθόδους ονομασίας. Αποτελείται από το συνδυασμό του ονόματος χώρου ονομάτων με τις ομάδες προορισμού. Για παράδειγμα:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Ετικέτες

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

podSelector:
  matchLabels:
    role: db

… ή χώρους ονομάτωνγια τα οποία ισχύουν. Αυτό το παράδειγμα επιλέγει όλα τα pods στους χώρους ονομάτων με τις αντίστοιχες ετικέτες:

namespaceSelector:
  matchLabels:
    project: myproject

Μία προσοχή: κατά τη χρήση namespaceSelector βεβαιωθείτε ότι οι χώροι ονομάτων που επιλέγετε περιέχουν τη σωστή ετικέτα. Έχετε υπόψη σας ότι οι ενσωματωμένοι χώροι ονομάτων όπως π.χ default и kube-system, από προεπιλογή δεν περιέχουν ετικέτες.

Μπορείτε να προσθέσετε μια ετικέτα σε ένα διάστημα όπως αυτό:

kubectl label namespace default namespace=default

Ταυτόχρονα, ο χώρος ονομάτων στην ενότητα metadata θα πρέπει να αναφέρεται στο πραγματικό όνομα του διαστήματος, όχι στην ετικέτα:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Πηγή και προορισμός

Οι πολιτικές τείχους προστασίας αποτελούνται από κανόνες με πηγές και προορισμούς. Οι πολιτικές δικτύου Kubernetes ορίζονται για έναν στόχο - ένα σύνολο ομάδων ομάδων στο οποίο εφαρμόζονται - και στη συνέχεια ορίζονται κανόνες για την κίνηση εισόδου ή/και εξόδου. Στο παράδειγμά μας, ο στόχος της πολιτικής θα είναι όλα τα pod στο χώρο ονομάτων default με ετικέτα με κλειδί app και νόημα db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

Αυτό ισοδυναμεί με δύο κανόνες τείχους προστασίας: Εισαγωγή → Στόχος. Στόχος → Έξοδος.

Egress και DNS (σημαντικό!)

Περιορίζοντας την εξερχόμενη κίνηση, δώστε ιδιαίτερη προσοχή στο DNS - Η Kubernetes χρησιμοποιεί αυτήν την υπηρεσία για να αντιστοιχίσει υπηρεσίες σε διευθύνσεις IP. Για παράδειγμα, η ακόλουθη πολιτική δεν θα λειτουργήσει επειδή δεν έχετε επιτρέψει την εφαρμογή balance πρόσβαση στο DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

Μπορείτε να το διορθώσετε ανοίγοντας την πρόσβαση στην υπηρεσία DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

Τελευταίο στοιχείο to είναι κενό και επομένως επιλέγει έμμεσα όλα τα pod σε όλους τους χώρους ονομάτων, επιτρέποντας balance στείλτε ερωτήματα DNS στην κατάλληλη υπηρεσία Kubernetes (συνήθως εκτελείται στο χώρο kube-system).

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

Μπορείτε να το βελτιώσετε σε τρία διαδοχικά βήματα.

1. Επιτρέπονται μόνο ερωτήματα DNS μέσα συστάδα προσθέτοντας namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. Να επιτρέπονται τα ερωτήματα DNS μόνο εντός του χώρου ονομάτων kube-system.

Για να γίνει αυτό πρέπει να προσθέσετε μια ετικέτα στο χώρο ονομάτων kube-system: kubectl label namespace kube-system namespace=kube-system - και καταγράψτε το στη χρήση πολιτικής namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Οι παρανοϊκοί άνθρωποι μπορούν να προχωρήσουν ακόμη περισσότερο και να περιορίσουν τα ερωτήματα DNS σε μια συγκεκριμένη υπηρεσία DNS kube-system. Η ενότητα "Φιλτράρισμα κατά χώρων ονομάτων ΚΑΙ λοβών" θα σας πει πώς να το πετύχετε αυτό.

Μια άλλη επιλογή είναι να επιλύσετε το DNS σε επίπεδο χώρου ονομάτων. Σε αυτήν την περίπτωση, δεν θα χρειαστεί να ανοίξει για κάθε υπηρεσία:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

Αδειάζω podSelector επιλέγει όλα τα pod στο χώρο ονομάτων.

Πρώτος αγώνας και σειρά κανόνων

Στα συμβατικά τείχη προστασίας, η ενέργεια (Allow or Deny) σε ένα πακέτο καθορίζεται από τον πρώτο κανόνα που αυτό ικανοποιεί. Στο Kubernetes, η σειρά των πολιτικών δεν έχει σημασία.

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

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

Κανόνας απογύμνωσης ("Άρνηση")

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

Δεν υπάρχει καμία άρνηση δράσης στο Kubernetes, ωστόσο, ένα παρόμοιο αποτέλεσμα μπορεί να επιτευχθεί με μια κανονική (επιτρεπτή) πολιτική επιλέγοντας μια κενή ομάδα λοβών πηγής (εισόδου):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

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

Με παρόμοιο τρόπο, μπορείτε να περιορίσετε όλη την εξερχόμενη κίνηση από έναν χώρο ονομάτων:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

Παρακαλώ σημειώστε ότι οποιεσδήποτε πρόσθετες πολιτικές που επιτρέπουν την επισκεψιμότητα σε ομάδες διαφημίσεων στον χώρο ονομάτων θα υπερισχύουν αυτού του κανόνα (παρόμοιο με την προσθήκη ενός κανόνα επιτρέπεται πριν από έναν κανόνα άρνησης σε μια διαμόρφωση τείχους προστασίας).

Να επιτρέπονται τα πάντα (Any-Any-Any-Allow)

Για να δημιουργήσετε μια πολιτική Να επιτρέπονται όλα, πρέπει να συμπληρώσετε την παραπάνω πολιτική άρνησης με ένα κενό στοιχείο ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

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

Ο κανόνας μπορεί να περιοριστεί για να επιτρέπεται η πρόσβαση μόνο σε ένα συγκεκριμένο σύνολο λοβών (app:balance) στον χώρο ονομάτων default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

Η ακόλουθη πολιτική επιτρέπει όλη την επισκεψιμότητα εισόδου και εξόδου, συμπεριλαμβανομένης της πρόσβασης σε οποιαδήποτε IP εκτός του συμπλέγματος:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

Συνδυασμός πολλαπλών πολιτικών

Οι πολιτικές συνδυάζονται χρησιμοποιώντας λογικά OR σε τρία επίπεδα. Τα δικαιώματα κάθε pod ορίζονται σύμφωνα με τον διαχωρισμό όλων των πολιτικών που το επηρεάζουν:

1. Στα χωράφια from и to Μπορούν να οριστούν τρεις τύποι στοιχείων (όλα τα οποία συνδυάζονται χρησιμοποιώντας OR):

• namespaceSelector — επιλέγει ολόκληρο τον χώρο ονομάτων.
• podSelector — επιλέγει λοβούς.
• ipBlock — επιλέγει ένα υποδίκτυο.

Επιπλέον, ο αριθμός των στοιχείων (ακόμη και πανομοιότυπα) σε υποενότητες from/to μη περιορισμένο. Όλα αυτά θα συνδυαστούν με λογικό OR.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. Μέσα στην ενότητα πολιτικής ingress μπορεί να έχει πολλά στοιχεία from (συνδυάζεται με λογικό OR). Ομοίως, το τμήμα egress μπορεί να περιλαμβάνει πολλά στοιχεία to (συνδυάζεται επίσης με διαχωρισμό):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. Διαφορετικές πολιτικές συνδυάζονται επίσης με λογικά OR

Αλλά όταν τα συνδυάζετε, υπάρχει ένας περιορισμός στον οποίο επεσήμανε Κρις Κούνεϊ: Το Kubernetes μπορεί να συνδυάσει πολιτικές μόνο με διαφορετικές policyTypes (Ingress ή Egress). Οι πολιτικές που ορίζουν την είσοδο (ή την έξοδο) θα αντικαθιστούν η μία την άλλη.

Σχέση μεταξύ χώρων ονομάτων

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

Αφού αποκλείσετε την πρόσβαση σε έναν χώρο ονομάτων (δείτε τον "Κανόνα απογύμνωσης" παραπάνω), μπορείτε να κάνετε εξαιρέσεις στην πολιτική άρνησης επιτρέποντας συνδέσεις από έναν συγκεκριμένο χώρο ονομάτων χρησιμοποιώντας namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

Ως αποτέλεσμα, όλα τα pods στον χώρο ονομάτων default θα έχει πρόσβαση σε λοβούς postgres στον χώρο ονομάτων database. Τι γίνεται όμως αν θέλετε να ανοίξετε την πρόσβαση σε postgres μόνο συγκεκριμένες ομάδες στο χώρο ονομάτων default?

Φιλτράρισμα κατά χώρους ονομάτων και λοβών

Kubernetes έκδοση 1.11 και νεότερη σας επιτρέπει να συνδυάσετε τελεστές namespaceSelector и podSelector χρησιμοποιώντας το λογικό ΚΑΙ. Μοιάζει με αυτό:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Γιατί αυτό ερμηνεύεται ως ΚΑΙ αντί για το συνηθισμένο Ή;

Σημειώστε ότι podSelector δεν ξεκινά με παύλα. Στο YAML αυτό σημαίνει ότι podSelector και στέκεται μπροστά του namespaceSelector ανατρέξτε στο ίδιο στοιχείο λίστας. Επομένως, συνδυάζονται με λογικά ΚΑΙ.

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

Για επιλογή λοβών με συγκεκριμένη ετικέτα σε όλους τους χώρους ονομάτων, εισάγετε κενό namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Πολλές ετικέτες συνεργάζονται με το I

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

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Αντίθετα, στο Kubernetes οι διάφορες ετικέτες σε podSelector ή namespaceSelector συνδυάζονται με το λογικό ΚΑΙ. Για παράδειγμα, ο ακόλουθος κανόνας θα επιλέξει ομάδες που έχουν και τις δύο ετικέτες, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Η ίδια λογική ισχύει για όλους τους τύπους τελεστών: επιλογείς στόχων πολιτικής, επιλογείς pod και επιλογείς χώρου ονομάτων.

Υποδίκτυα και διευθύνσεις IP (IPBlocks)

Τα τείχη προστασίας χρησιμοποιούν VLAN, διευθύνσεις IP και υποδίκτυα για να τμηματοποιήσουν ένα δίκτυο.

Στο Kubernetes, οι διευθύνσεις IP εκχωρούνται σε pods αυτόματα και μπορούν να αλλάζουν συχνά, επομένως οι ετικέτες χρησιμοποιούνται για την επιλογή ομάδων και χώρων ονομάτων στις πολιτικές δικτύου.

Υποδίκτυα (ipBlocks) χρησιμοποιούνται κατά τη διαχείριση εισερχόμενων (εισόδου) ή εξερχόμενων (εξόδου) εξωτερικών συνδέσεων (Βορράς-Νότου). Για παράδειγμα, αυτή η πολιτική ανοίγει σε όλα τα pods από τον χώρο ονομάτων default πρόσβαση στην υπηρεσία Google DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Ο κενός επιλογέας pod σε αυτό το παράδειγμα σημαίνει "επιλογή όλων των ομάδων στο χώρο ονομάτων".

Αυτή η πολιτική επιτρέπει μόνο την πρόσβαση στο 8.8.8.8. η πρόσβαση σε οποιαδήποτε άλλη IP απαγορεύεται. Έτσι, στην ουσία, έχετε αποκλείσει την πρόσβαση στην εσωτερική υπηρεσία DNS του Kubernetes. Εάν εξακολουθείτε να θέλετε να το ανοίξετε, δηλώστε το ρητά.

Συνήθως ipBlocks и podSelectors είναι αμοιβαία αποκλειόμενες, καθώς οι εσωτερικές διευθύνσεις IP των pods δεν χρησιμοποιούνται σε ipBlocks. Υποδεικνύοντας εσωτερικά IP pods, θα επιτρέψετε στην πραγματικότητα συνδέσεις προς/από pods με αυτές τις διευθύνσεις. Στην πράξη, δεν θα ξέρετε ποια διεύθυνση IP να χρησιμοποιήσετε, γι' αυτό δεν θα πρέπει να χρησιμοποιούνται για την επιλογή ομάδων.

Ως αντί-παράδειγμα, η ακόλουθη πολιτική περιλαμβάνει όλες τις IP και επομένως επιτρέπει την πρόσβαση σε όλα τα άλλα pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

Μπορείτε να ανοίξετε πρόσβαση μόνο σε εξωτερικές IP, εξαιρουμένων των εσωτερικών διευθύνσεων IP των pod. Για παράδειγμα, εάν το υποδίκτυο του pod σας είναι 10.16.0.0/14:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

Θύρες και πρωτόκολλα

Συνήθως τα pod ακούνε μια θύρα. Αυτό σημαίνει ότι μπορείτε απλά να μην καθορίσετε αριθμούς θύρας στις πολιτικές και να αφήσετε τα πάντα ως προεπιλογή. Ωστόσο, συνιστάται να κάνετε τις πολιτικές όσο το δυνατόν πιο περιοριστικές, επομένως σε ορισμένες περιπτώσεις μπορείτε να καθορίσετε θύρες:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Σημειώστε ότι ο επιλογέας ports ισχύει για όλα τα στοιχεία του μπλοκ to ή from, που περιέχει. Για να καθορίσετε διαφορετικές θύρες για διαφορετικά σύνολα στοιχείων, διαχωρίστε ingress ή egress σε πολλές υποενότητες με to ή from και σε κάθε εγγραφή των θυρών σας:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Προεπιλεγμένη λειτουργία θύρας:

• Εάν παραλείψετε εντελώς τον ορισμό της θύρας (ports), αυτό σημαίνει όλα τα πρωτόκολλα και όλες τις θύρες.
• Εάν παραλείψετε τον ορισμό του πρωτοκόλλου (protocol), αυτό σημαίνει TCP.
• Εάν παραλείψετε τον ορισμό της θύρας (port), αυτό σημαίνει όλες τις θύρες.

Βέλτιστη πρακτική: Μην βασίζεστε σε προεπιλεγμένες τιμές, καθορίστε ρητά τι χρειάζεστε.

Λάβετε υπόψη ότι πρέπει να χρησιμοποιείτε θύρες pod, όχι θύρες υπηρεσίας (περισσότερα για αυτό στην επόμενη παράγραφο).

Ορίζονται πολιτικές για ομάδες διαφημίσεων ή υπηρεσίες;

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

Για παράδειγμα, εάν μια υπηρεσία ακούει τη θύρα 80, αλλά ανακατευθύνει την κυκλοφορία στη θύρα 8080 των pod της, πρέπει να καθορίσετε ακριβώς το 8080 στην πολιτική δικτύου.

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

Νέα αρχιτεκτονική προσέγγιση με χρήση Service Mesh (για παράδειγμα, βλ. για το Ιστιο παρακάτω - περίπου μετάφρ.) σας επιτρέπει να αντιμετωπίσετε αυτό το πρόβλημα.

Είναι απαραίτητη η εγγραφή και εισόδου και εξόδου;

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

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

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

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

Βλ. Πολιτεία ή Απάτριδα παρακάτω.

κούτσουρα

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

Έλεγχος κίνησης προς εξωτερικές υπηρεσίες

Οι πολιτικές δικτύου Kubernetes δεν σας επιτρέπουν να καθορίσετε ένα πλήρως αναγνωρισμένο όνομα τομέα (DNS) στις ενότητες εξόδου. Αυτό το γεγονός οδηγεί σε σημαντική ταλαιπωρία κατά την προσπάθεια περιορισμού της κυκλοφορίας σε εξωτερικούς προορισμούς που δεν έχουν σταθερή διεύθυνση IP (όπως το aws.com).

Έλεγχος πολιτικής

Τα τείχη προστασίας θα σας προειδοποιήσουν ή ακόμη και θα αρνηθούν να αποδεχτείτε τη λάθος πολιτική. Η Kubernetes κάνει επίσης κάποια επαλήθευση. Όταν ορίζετε μια πολιτική δικτύου μέσω του kubectl, η Kubernetes μπορεί να δηλώσει ότι είναι εσφαλμένη και να αρνηθεί να την αποδεχτεί. Σε άλλες περιπτώσεις, η Kubernetes θα λάβει την πολιτική και θα τη συμπληρώσει με τα στοιχεία που λείπουν. Μπορούν να φανούν χρησιμοποιώντας την εντολή:

kubernetes get networkpolicy <policy-name> -o yaml

Λάβετε υπόψη ότι το σύστημα επικύρωσης Kubernetes δεν είναι αλάνθαστο και μπορεί να παραλείψει ορισμένους τύπους σφαλμάτων.

Εκτέλεση

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

Σημειώστε ότι η Kubernetes δεν θα σας προειδοποιήσει εάν ορίσετε μια πολιτική δικτύου χωρίς τον κατάλληλο βοηθό CNI.

Κράτος ή Ανιθαγενής;

Όλα τα Kubernetes CNI που έχω συναντήσει είναι stateful (για παράδειγμα, το Calico χρησιμοποιεί Linux conntrack). Αυτό επιτρέπει στο pod να λαμβάνει απαντήσεις στη σύνδεση TCP που ξεκίνησε χωρίς να χρειάζεται να την αποκαταστήσει. Ωστόσο, δεν γνωρίζω ένα πρότυπο Kubernetes που θα εγγυάται την κρατικότητα.

Προηγμένη Διαχείριση Πολιτικής Ασφαλείας

Ακολουθούν ορισμένοι τρόποι βελτίωσης της επιβολής της πολιτικής ασφαλείας στο Kubernetes:

1. Το αρχιτεκτονικό μοτίβο Service Mesh χρησιμοποιεί κοντέινερ για την παροχή λεπτομερούς τηλεμετρίας και ελέγχου της κυκλοφορίας σε επίπεδο υπηρεσιών. Ως παράδειγμα μπορούμε να πάρουμε Ίστιο.
2. Ορισμένοι από τους προμηθευτές CNI έχουν επεκτείνει τα εργαλεία τους για να υπερβούν τις πολιτικές δικτύου Kubernetes.
3. Tufin Orca Παρέχει ορατότητα και αυτοματοποίηση των πολιτικών δικτύου Kubernetes.

Το πακέτο Tufin Orca διαχειρίζεται τις πολιτικές δικτύου Kubernetes (και είναι η πηγή των παραπάνω στιγμιότυπων οθόνης).

Επιπλέον χαρακτηριστικά

• Παραδείγματα πολιτικών δικτύου που εκπόνησε ο Ahmet Alp Balkan από το ΓΚΕ;
• Τεκμηρίωση από τον επίσημο ιστότοπο της Kubernetes;
• Ένας οδηγός για το μοντέλο δικτύωσης Kubernetes;
• Σενάριο για έλεγχο πολιτικών δικτύου.

Συμπέρασμα

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

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

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• "Επιστροφή στις μικροϋπηρεσίες με Istio": μέρος 1 (εισαγωγή στα κύρια χαρακτηριστικά), μέρος 2 (δρομολόγηση, έλεγχος κυκλοφορίας), μέρος 3 (ασφάλεια);
• "Ένας εικονογραφημένος οδηγός για τη δικτύωση στο Kubernetes": μέρη 1 και 2 (μοντέλο δικτύου, δίκτυα επικάλυψης), μέρος 3 (υπηρεσίες και διεκπεραίωση κυκλοφορίας);
• «Docker και Kubernetes σε περιβάλλοντα ευαίσθητα στην ασφάλεια"?
• «9 βέλτιστες πρακτικές για την ασφάλεια Kubernetes"?
• «11 Τρόποι για να (Μην) Γίνετε Θύμα Hack της Kubernetes».

Πηγή: www.habr.com