Kubelet Authentication & Authorization

Μάθετε το hacking στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

• Αν θέλετε να δείτε την εταιρεία σας να διαφημίζεται στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΣΧΕΔΙΑ ΣΥΝΔΡΟΜΗΣ!

• Αποκτήστε το επίσημο PEASS & HackTricks swag

• Ανακαλύψτε την Οικογένεια PEASS, τη συλλογή μας από αποκλειστικά NFTs

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε με στο Twitter 🐦 @carlospolopm.

• Μοιραστείτε τα hacking tricks σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.

Πιστοποίηση του Kubelet

Από τα έγγραφα:

Από προεπιλογή, οι αιτήσεις προς το HTTPS endpoint του kubelet που δεν απορρίπτονται από άλλες παραμετροποιημένες μεθόδους πιστοποίησης θεωρούνται ως ανώνυμες αιτήσεις και δίνονται ένα όνομα χρήστη system:anonymous και μια ομάδα system:unauthenticated.

Οι 3 μέθοδοι πιστοποίησης είναι:

• Ανώνυμη (προεπιλογή): Χρησιμοποιήστε την ρύθμιση --anonymous-auth=true ή τον παραμετροποιημένο κατάλογο:

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook: Αυτό θα ενεργοποιήσει τα κλειδιά πρόσβασης API του kubectl ως αδειοδότηση (οποιοδήποτε έγκυρο κλειδί θα είναι έγκυρο). Επιτρέψτε το με:

• βεβαιωθείτε ότι η ομάδα API authentication.k8s.io/v1beta1 είναι ενεργοποιημένη στον διακομιστή API

• ξεκινήστε το kubelet με τις σημαίες --authentication-token-webhook και --kubeconfig ή χρησιμοποιήστε την παρακάτω ρύθμιση:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Το kubelet καλεί το TokenReview API στον διαμορφωμένο API server για να προσδιορίσει πληροφορίες χρήστη από τα bearer tokens.

• Πιστοποιητικά πελάτη X509: Επιτρέπουν την πιστοποίηση μέσω πιστοποιητικών πελάτη X509

• Δείτε την τεκμηρίωση πιστοποίησης apiserver για περισσότερες λεπτομέρειες

• Ξεκινήστε το kubelet με τη σημαία --client-ca-file, παρέχοντας ένα αρχείο CA bundle για τον έλεγχο των πιστοποιητικών πελατών. Ή με τη διαμόρφωση:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Εξουσιοδότηση Kubelet

Οποιοδήποτε αίτημα που έχει επιτυχή πιστοποίηση (συμπεριλαμβανομένου ενός ανώνυμου αιτήματος) εξουσιοδοτείται. Ο προεπιλεγμένος τρόπος εξουσιοδότησης είναι ο AlwaysAllow, ο οποίος επιτρέπει όλα τα αιτήματα.

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

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

Η εξουσιοδότηση μέσω webhook μπορεί να ρυθμιστεί χρησιμοποιώντας την παράμετρο --authorization-mode=Webhook ή μέσω του αρχείου διαμόρφωσης με:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

Το kubelet καλεί το API SubjectAccessReview στον διαμορφωμένο API server για να καθορίσει εάν κάθε αίτηση είναι εξουσιοδοτημένη.

Το kubelet εξουσιοδοτεί τις αιτήσεις API χρησιμοποιώντας την ίδια προσέγγιση χαρακτηριστικών αιτήματος όπως το apiserver:

• Ενέργεια

HTTP ρήμα	ρήμα αίτησης
POST	create
GET, HEAD	get (για μεμονωμένους πόρους), list (για συλλογές, συμπεριλαμβανομένου του πλήρους περιεχομένου αντικειμένου), watch (για παρακολούθηση ενός μεμονωμένου πόρου ή συλλογής πόρων)
PUT	update
PATCH	patch
DELETE	delete (για μεμονωμένους πόρους), deletecollection (για συλλογές)

• Ο πόρος που επικοινωνεί με το Kubelet api είναι πάντα κόμβοι και ο υποπόρος καθορίζεται από τη διαδρομή του εισερχόμενου αιτήματος:

Kubelet API	πόρος	υποπόρος
/stats/*	κόμβοι	στατιστικά
/metrics/*	κόμβοι	μετρήσεις
/logs/*	κόμβοι	καταγραφή
/spec/*	κόμβοι	προδιαγραφή
όλα τα άλλα	κόμβοι	διαμεσολαβητής

Για παράδειγμα, η παρακάτω αίτηση προσπάθησε να αποκτήσει πρόσβαση στις πληροφορίες των pods του kubelet χωρίς άδεια:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

• Πήραμε ένα Απαγορευμένο, οπότε το αίτημα πέρασε τον έλεγχο Ταυτοποίησης. Αν δεν ήταν έτσι, θα είχαμε λάβει απλά ένα μήνυμα Μη εξουσιοδοτημένο.

• Μπορούμε να δούμε το όνομα χρήστη (σε αυτήν την περίπτωση από το τοκέν)

• Ελέγξτε πώς ο πόρος ήταν κόμβοι και ο υποπόρος proxy (που έχει νόημα με βάση τις προηγούμενες πληροφορίες)

Αναφορές

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/

Μάθετε το χάκινγκ του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

• Αν θέλετε να δείτε την εταιρεία σας να διαφημίζεται στο HackTricks ή να κατεβάσετε το HackTricks σε μορφή PDF ελέγξτε τα ΠΑΚΕΤΑ ΣΥΝΔΡΟΜΗΣ!

• Αποκτήστε το επίσημο PEASS & HackTricks swag

• Ανακαλύψτε The PEASS Family, τη συλλογή μας από αποκλειστικά NFTs

• Εγγραφείτε στη 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε με στο Twitter 🐦 @carlospolopm.

• Μοιραστείτε τα χάκινγκ κόλπα σας υποβάλλοντας PRs στα HackTricks και HackTricks Cloud αποθετήρια του github.