Πιστοποίηση & Εξουσιοδότηση Kubelet
Tip
Μάθετε & εξασκηθείτε στο AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Υποστηρίξτε το HackTricks
- Δείτε τα subscription plans!
- Εγγραφείτε στο 💬 Discord group ή την telegram group ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
- Μοιραστείτε τα hacking tricks υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.
Πιστοποίηση Kubelet
Από προεπιλογή, τα αιτήματα προς το HTTPS endpoint του kubelet που δεν απορρίπτονται από άλλες ρυθμισμένες μεθόδους ελέγχου ταυτότητας αντιμετωπίζονται ως ανώνυμα αιτήματα και τους δίνεται ένα όνομα χρήστη system:anonymous και μια ομάδα system:unauthenticated.
Οι 3 μέθοδοι ελέγχου ταυτότητας είναι:
- Anonymous (προεπιλογή): Χρησιμοποιείται εάν οριστεί η παράμετρος
--anonymous-auth=trueή η ρύθμιση:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: Αυτό θα ενεργοποιήσει τα kubectl API bearer tokens ως εξουσιοδότηση (οποιοδήποτε έγκυρο token θα είναι έγκυρο). Επιτρέψτε το με:
- βεβαιωθείτε ότι το
authentication.k8s.io/v1beta1API group είναι ενεργοποιημένο στον API server - ξεκινήστε το kubelet με τις σημαίες
--authentication-token-webhookκαι--kubeconfigή χρησιμοποιήστε την ακόλουθη ρύθμιση:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
Το kubelet καλεί το
TokenReviewAPI στον ρυθμισμένο API server για να προσδιορίσει πληροφορίες χρήστη από bearer tokens
- X509 client certificates: Επιτρέπουν την αυθεντικοποίηση μέσω X509 client certificates
- δείτε την apiserver authentication documentation για περισσότερες λεπτομέρειες
- ξεκινήστε το kubelet με το flag
--client-ca-file, παρέχοντας ένα CA bundle για την επαλήθευση των πιστοποιητικών πελάτη. Ή με τη ρύθμιση:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Kubelet Authorization
Οποιοδήποτε αίτημα που έχει ταυτοποιηθεί επιτυχώς (συμπεριλαμβανομένου ενός ανώνυμου αιτήματος) εξουσιοδοτείται στη συνέχεια. Η προεπιλεγμένη λειτουργία εξουσιοδότησης είναι AlwaysAllow, η οποία επιτρέπει όλα τα αιτήματα.
Ωστόσο, η άλλη πιθανή τιμή είναι webhook (που είναι αυτή που θα βρείτε κυρίως εκεί έξω). Αυτή η λειτουργία θα ελέγξει τα δικαιώματα του ταυτοποιημένου χρήστη για να επιτρέψει ή να απορρίψει μια ενέργεια.
Warning
Σημειώστε ότι ακόμη και αν η ανώνυμη ταυτοποίηση είναι ενεργοποιημένη η ανώνυμη πρόσβαση μπορεί να μην έχει καθόλου δικαιώματα για να εκτελέσει οποιαδήποτε ενέργεια.
Η εξουσιοδότηση μέσω webhook μπορεί να ρυθμιστεί χρησιμοποιώντας την παράμετρο --authorization-mode=Webhook ή μέσω του αρχείου διαμόρφωσης με:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
Το kubelet καλεί το SubjectAccessReview API στον διαμορφωμένο API server για να καθορίσει εάν κάθε αίτημα είναι εξουσιοδοτημένο.
Το kubelet εξουσιοδοτεί αιτήματα API χρησιμοποιώντας την ίδια request attributes προσέγγιση με τον apiserver:
- Ενέργεια
| HTTP verb | request verb |
|---|---|
| POST | create |
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
| PUT | update |
| PATCH | patch |
| DELETE | delete (for individual resources), deletecollection (for collections) |
- Ο resource που επικοινωνεί με το Kubelet api είναι πάντα οι nodes και το subresource καθορίζεται από το path του εισερχόμενου αιτήματος:
| Kubelet API | resource | subresource |
|---|---|---|
| /stats/* | nodes | stats |
| /metrics/* | nodes | metrics |
| /logs/* | nodes | log |
| /spec/* | nodes | spec |
| all others | nodes | proxy |
Note
WebSocket-based
/exec,/run,/attach, and/portforwardfall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with onlynodes/proxyGET can still exec containers if it connects directly tohttps://<node_ip>:10250over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.
Για παράδειγμα, το ακόλουθο αίτημα προσπάθησε να αποκτήσει πρόσβαση στις πληροφορίες των 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)
- Λάβαμε ένα Forbidden, άρα το αίτημα passed the Authentication check. Αν όχι, θα είχαμε λάβει απλώς ένα
Unauthorisedμήνυμα. - Μπορούμε να δούμε το username (σε αυτή την περίπτωση από το token)
- Δες πώς το resource ήταν nodes και το subresource proxy (που έχει νόημα με τις προηγούμενες πληροφορίες)
Αναφορές
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
Μάθετε & εξασκηθείτε στο AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Υποστηρίξτε το HackTricks
- Δείτε τα subscription plans!
- Εγγραφείτε στο 💬 Discord group ή την telegram group ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
- Μοιραστείτε τα hacking tricks υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.
HackTricks Cloud

