Το ABC of Security στο Kubernetes: Έλεγχος ταυτότητας, εξουσιοδότηση, έλεγχος

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

Έλεγχος ταυτότητας

Υπάρχουν δύο τύποι χρηστών στο Kubernetes:

• Λογαριασμοί υπηρεσιών — λογαριασμοί που διαχειρίζονται το Kubernetes API·
• Χρήστες — «κανονικοί» χρήστες που διαχειρίζονται εξωτερικές, ανεξάρτητες υπηρεσίες.

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

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

Κάθε αίτημα API συσχετίζεται είτε με Λογαριασμό Υπηρεσίας, είτε με Χρήστη ή θεωρείται ανώνυμο.

Τα δεδομένα ελέγχου ταυτότητας χρήστη περιλαμβάνουν:

• Επωνυμία Φαρμακείου — όνομα χρήστη (με διάκριση πεζών-κεφαλαίων!).
• UID - μια συμβολοσειρά αναγνώρισης χρήστη αναγνώσιμη από μηχανή που είναι "πιο συνεπής και μοναδική από το όνομα χρήστη".
• Ομάδες — κατάλογος ομάδων στις οποίες ανήκει ο χρήστης·
• Εξτρα - πρόσθετα πεδία που μπορούν να χρησιμοποιηθούν από τον μηχανισμό εξουσιοδότησης.

Το Kubernetes μπορεί να χρησιμοποιήσει μεγάλο αριθμό μηχανισμών ελέγχου ταυτότητας: πιστοποιητικά X509, διακριτικά φορέα, διακομιστή μεσολάβησης ελέγχου ταυτότητας, Βασική ταυτότητα HTTP. Χρησιμοποιώντας αυτούς τους μηχανισμούς, μπορείτε να εφαρμόσετε έναν μεγάλο αριθμό σχημάτων εξουσιοδότησης: από ένα στατικό αρχείο με κωδικούς πρόσβασης έως το OpenID OAuth2.

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

• διακριτικά λογαριασμού υπηρεσίας - για λογαριασμούς υπηρεσιών.
• X509 - για χρήστες.

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

Πιστοποιητικά για χρήστες (X.509)

Ο κλασικός τρόπος εργασίας με πιστοποιητικά περιλαμβάνει:

• βασική γενιά:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• δημιουργία αιτήματος πιστοποιητικού:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• επεξεργασία ενός αιτήματος πιστοποιητικού χρησιμοποιώντας τα κλειδιά CA συμπλέγματος Kubernetes, απόκτηση πιστοποιητικού χρήστη (για να αποκτήσετε ένα πιστοποιητικό, πρέπει να χρησιμοποιήσετε έναν λογαριασμό που έχει πρόσβαση στο κλειδί CA συμπλέγματος Kubernetes, το οποίο από προεπιλογή βρίσκεται στο /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• δημιουργία αρχείου ρυθμίσεων:
  • περιγραφή του συμπλέγματος (καθορίστε τη διεύθυνση και τη θέση του αρχείου πιστοποιητικού CA της συγκεκριμένης εγκατάστασης συμπλέγματος):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • ή πώς όχιπροτεινόμενη επιλογή - δεν χρειάζεται να καθορίσετε το πιστοποιητικό ρίζας (τότε το kubectl δεν θα ελέγξει την ορθότητα του διακομιστή api του συμπλέγματος):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • προσθήκη χρήστη στο αρχείο διαμόρφωσης:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • προσθήκη πλαισίου:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • προεπιλεγμένη ανάθεση περιβάλλοντος:

    kubectl config use-context mynewuser-context

Μετά τους παραπάνω χειρισμούς, στο αρχείο .kube/config θα δημιουργηθεί μια ρύθμιση όπως αυτή:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

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

• certificate-authority
• client-certificate
• client-key

Για να το κάνετε αυτό, μπορείτε να κωδικοποιήσετε τα αρχεία που καθορίζονται σε αυτά χρησιμοποιώντας το base64 και να τα καταχωρήσετε στο config, προσθέτοντας το επίθημα στο όνομα των κλειδιών -data, δηλ. έχοντας λάβει certificate-authority-data κλπ.

Πιστοποιητικά με kubeadm

Με την απελευθέρωση Κουμπερνέτες 1.15 Η εργασία με πιστοποιητικά έχει γίνει πολύ πιο εύκολη χάρη στην alpha έκδοση της υποστήριξής του βοηθητικό πρόγραμμα kubeadm. Για παράδειγμα, η δημιουργία ενός αρχείου διαμόρφωσης με κλειδιά χρήστη μπορεί να μοιάζει με αυτό:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: Απαιτείται διεύθυνση διαφήμισης μπορεί να βρεθεί στο api-server config, ο οποίος βρίσκεται από προεπιλογή /etc/kubernetes/manifests/kube-apiserver.yaml.

Η διαμόρφωση που προκύπτει θα βγει στο stdout. Πρέπει να αποθηκευτεί ~/.kube/config λογαριασμό χρήστη ή σε ένα αρχείο που καθορίζεται σε μια μεταβλητή περιβάλλοντος KUBECONFIG.

Σκάβουμε βαθύτερα

Για όσους θέλουν να κατανοήσουν τα ζητήματα που περιγράφονται λεπτομερέστερα:

• ξεχωριστό άρθρο σχετικά με την εργασία με πιστοποιητικά στην επίσημη τεκμηρίωση της Kubernetes.
• καλό άρθρο από το Bitnami, στο οποίο θίγεται από πρακτική άποψη η έκδοση των πιστοποιητικών.
• γενική τεκμηρίωση σχετικά με τον έλεγχο ταυτότητας στο Kubernetes.

Είσοδος

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

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

Ο πραγματικός (και πιο ευέλικτος) τρόπος διαχωρισμού των δικαιωμάτων πρόσβασης σε ένα σύμπλεγμα ονομάζεται RBAC (Έλεγχος πρόσβασης βάσει ρόλου). Έχει δηλωθεί σταθερό από την έκδοση Κουμπερνέτες 1.8. Το RBAC εφαρμόζει ένα μοντέλο δικαιωμάτων στο οποίο απαγορεύεται οτιδήποτε δεν επιτρέπεται ρητά.
Για να ενεργοποιήσετε το RBAC, πρέπει να ξεκινήσετε το Kubernetes api-server με την παράμετρο --authorization-mode=RBAC. Οι παράμετροι ορίζονται στο μανιφέστο με τη διαμόρφωση διακομιστή api, ο οποίος από προεπιλογή βρίσκεται κατά μήκος της διαδρομής /etc/kubernetes/manifests/kube-apiserver.yaml, στο τμήμα command. Ωστόσο, το RBAC είναι ήδη ενεργοποιημένο από προεπιλογή, οπότε πιθανότατα δεν πρέπει να ανησυχείτε για αυτό: μπορείτε να το επαληθεύσετε από την τιμή authorization-mode (στα προαναφερθέντα kube-apiserver.yaml). Παρεμπιπτόντως, μεταξύ των εννοιών του μπορεί να υπάρχουν και άλλοι τύποι εξουσιοδότησης (node, webhook, always allow), αλλά θα αφήσουμε την εξέτασή τους εκτός του πλαισίου του υλικού.

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

Οι ακόλουθες οντότητες API χρησιμοποιούνται για τον έλεγχο της πρόσβασης στο Kubernetes μέσω RBAC:

• Role и ClusterRole — ρόλοι που χρησιμεύουν για την περιγραφή των δικαιωμάτων πρόσβασης:
• Role σας επιτρέπει να περιγράφετε δικαιώματα εντός ενός χώρου ονομάτων.
• ClusterRole - εντός του συμπλέγματος, συμπεριλαμβανομένων των αντικειμένων που σχετίζονται με το σύμπλεγμα, όπως οι κόμβοι, οι διευθύνσεις URL χωρίς πόρους (δηλαδή που δεν σχετίζονται με πόρους Kubernetes - για παράδειγμα, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - χρησιμοποιείται για δέσιμο Role и ClusterRole σε έναν χρήστη, ομάδα χρηστών ή λογαριασμό υπηρεσίας.

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

Οι ρόλοι περιγράφουν δικαιώματα χρησιμοποιώντας σύνολα κανόνων που περιέχουν:

• Ομάδες API - βλ επίσημη τεκμηρίωση από apiGroups και έξοδο kubectl api-resources;
• πόροι (πόροι: pod, namespace, deployment και ούτω καθεξής.);
• Ρήματα (ρήματα: set, update κ.λπ.).
• ονόματα πόρων (resourceNames) - για την περίπτωση που πρέπει να παρέχετε πρόσβαση σε έναν συγκεκριμένο πόρο και όχι σε όλους τους πόρους αυτού του τύπου.

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

Παραδείγματα οντοτήτων RBAC

Απλή Role, το οποίο σας επιτρέπει να λαμβάνετε μια λίστα και την κατάσταση των pods και να τα παρακολουθείτε στον χώρο ονομάτων target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Παράδειγμα ClusterRole, που σας επιτρέπει να λαμβάνετε μια λίστα και την κατάσταση των ομάδων και να τα παρακολουθείτε σε όλο το σύμπλεγμα:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Παράδειγμα RoleBinding, που επιτρέπει στο χρήστη mynewuser "διάβασμα" λοβών στον χώρο ονομάτων my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

Έλεγχος εκδήλωσης

Σχηματικά, η αρχιτεκτονική Kubernetes μπορεί να αναπαρασταθεί ως εξής:

Το βασικό στοιχείο Kubernetes που είναι υπεύθυνο για την επεξεργασία αιτημάτων είναι api-server. Όλες οι λειτουργίες στο σύμπλεγμα περνούν από αυτό. Μπορείτε να διαβάσετε περισσότερα για αυτούς τους εσωτερικούς μηχανισμούς στο άρθρο "Τι συμβαίνει στο Kubernetes όταν εκτελείτε το kubectl run;».

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

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

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

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

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

Αλλά δεν θα σταθούμε σε αυτά με περισσότερες λεπτομέρειες - μπορείτε να βρείτε όλες τις λεπτομέρειες τεκμηρίωση kube-apiserver.

Όπως αναφέρθηκε ήδη, όλες οι παράμετροι ορίζονται στο μανιφέστο με τη διαμόρφωση διακομιστή api (από προεπιλογή /etc/kubernetes/manifests/kube-apiserver.yaml), στο τμήμα command. Ας επιστρέψουμε στις 3 απαιτούμενες παραμέτρους και ας τις αναλύσουμε:

1. audit-policy-file — διαδρομή προς το αρχείο YAML που περιγράφει την πολιτική ελέγχου. Θα επιστρέψουμε στο περιεχόμενό του, αλλά προς το παρόν θα σημειώσω ότι το αρχείο πρέπει να είναι αναγνώσιμο από τη διαδικασία api-server. Επομένως, πρέπει να το τοποθετήσετε μέσα στο κοντέινερ, για το οποίο μπορείτε να προσθέσετε τον ακόλουθο κώδικα στις κατάλληλες ενότητες της διαμόρφωσης:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path — διαδρομή προς το αρχείο καταγραφής. Η διαδρομή πρέπει επίσης να είναι προσβάσιμη στη διαδικασία του διακομιστή api, επομένως περιγράφουμε την προσάρτησή της με τον ίδιο τρόπο:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format — μορφή αρχείου καταγραφής ελέγχου. Η προεπιλογή είναι json, αλλά η μορφή κειμένου παλαιού τύπου είναι επίσης διαθέσιμη (legacy).

Πολιτική Ελέγχου

Τώρα σχετικά με το αναφερόμενο αρχείο που περιγράφει την πολιτική καταγραφής. Η πρώτη έννοια της πολιτικής ελέγχου είναι level, επίπεδο καταγραφής. Είναι οι εξής:

• None - Μην καταγράφετε
• Metadata — καταγραφή μεταδεδομένων αιτήματος: χρήστης, χρόνος αιτήματος, πόρος στόχος (pod, χώρος ονομάτων, κ.λπ.), τύπος ενέργειας (ρήμα) κ.λπ.
• Request — μεταδεδομένα καταγραφής και σώμα αιτήματος·
• RequestResponse — μεταδεδομένα καταγραφής, σώμα αιτήματος και σώμα απάντησης.

Τα δύο τελευταία επίπεδα (Request и RequestResponse) μην καταγράφετε αιτήματα που δεν είχαν πρόσβαση σε πόρους (πρόσβαση στα λεγόμενα url χωρίς πόρους).

Επίσης όλα τα αιτήματα περνούν διάφορα στάδια:

• RequestReceived - το στάδιο κατά το οποίο το αίτημα λαμβάνεται από τον χειριστή και δεν έχει ακόμη μεταφερθεί περαιτέρω κατά μήκος της αλυσίδας των χειριστών·
• ResponseStarted — οι κεφαλίδες απαντήσεων αποστέλλονται, αλλά πριν αποσταλεί το σώμα απάντησης. Δημιουργήθηκε για μακροχρόνια ερωτήματα (για παράδειγμα, watch);
• ResponseComplete — ο φορέας απάντησης έχει σταλεί, δεν θα σταλούν περισσότερες πληροφορίες·
• Panic — δημιουργούνται συμβάντα όταν εντοπίζεται μια μη φυσιολογική κατάσταση.

Για να παραλείψετε τυχόν βήματα που μπορείτε να χρησιμοποιήσετε omitStages.

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

Ο δαίμονας kubelet παρακολουθεί τις αλλαγές στο μανιφέστο με τη διαμόρφωση του διακομιστή api και, εάν εντοπιστούν, επανεκκινεί το κοντέινερ με τον διακομιστή api. Υπάρχει όμως μια σημαντική λεπτομέρεια: Οι αλλαγές στο αρχείο πολιτικής θα αγνοηθούν από αυτό. Αφού κάνετε αλλαγές στο αρχείο πολιτικής, θα χρειαστεί να κάνετε επανεκκίνηση του διακομιστή api με μη αυτόματο τρόπο. Δεδομένου ότι ο διακομιστής api ξεκινά ως στατικό λοβό, ομάδα kubectl delete δεν θα προκαλέσει επανεκκίνηση. Θα πρέπει να το κάνετε χειροκίνητα docker stop στο kube-masters, όπου η πολιτική ελέγχου έχει αλλάξει:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Όταν ενεργοποιείτε τον έλεγχο, είναι σημαντικό να το θυμάστε αυτό το φορτίο στο kube-apiserver αυξάνεται. Συγκεκριμένα, η κατανάλωση μνήμης για την αποθήκευση του πλαισίου αιτήματος αυξάνεται. Η καταγραφή ξεκινά μόνο μετά την αποστολή της κεφαλίδας απόκρισης. Το φορτίο εξαρτάται επίσης από τη διαμόρφωση της πολιτικής ελέγχου.

Παραδείγματα πολιτικών

Ας δούμε τη δομή των αρχείων πολιτικής χρησιμοποιώντας παραδείγματα.

Εδώ είναι ένα απλό αρχείο policyγια να καταγράψετε τα πάντα στο επίπεδο Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Στην πολιτική μπορείτε να καθορίσετε μια λίστα χρηστών (Users и ServiceAccounts) και ομάδες χρηστών. Για παράδειγμα, έτσι θα αγνοήσουμε τους χρήστες του συστήματος, αλλά θα καταγράψουμε όλα τα άλλα στο επίπεδο Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Είναι επίσης δυνατό να περιγραφούν οι στόχοι:

• χώροι ονομάτων (namespaces);
• Ρήματα (ρήματα: get, update, delete και άλλοι);
• πόροι (πόροι, Ως εξής: pod, configmaps κ.λπ.) και ομάδες πόρων (apiGroups).

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

kubectl api-resources
kubectl api-versions

Η ακόλουθη πολιτική ελέγχου παρέχεται ως επίδειξη των βέλτιστων πρακτικών στο Τεκμηρίωση Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

Ένα άλλο καλό παράδειγμα πολιτικής ελέγχου είναι προφίλ που χρησιμοποιείται στο GCE.

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

Αποτελέσματα της

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

PS

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

• «33+ εργαλεία ασφαλείας Kubernetes"?
• «Εισαγωγή στις πολιτικές δικτύου Kubernetes για επαγγελματίες ασφαλείας"?
• «Κατανόηση του RBAC στο Kubernetes"?
• «9 βέλτιστες πρακτικές για την ασφάλεια Kubernetes"?
• «11 Τρόποι για να (Μην) Γίνετε Θύμα Hack της Kubernetes».

Πηγή: www.habr.com