Πιστοποίηση & Εξουσιοδότηση 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

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

From the docss:

Από προεπιλογή, τα αιτήματα προς το 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/v1beta1 API group είναι ενεργοποιημένο στον API server
  • ξεκινήστε το kubelet με τις σημαίες --authentication-token-webhook και --kubeconfig ή χρησιμοποιήστε την ακόλουθη ρύθμιση:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

Το kubelet καλεί το TokenReview API στον ρυθμισμένο 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 verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • Ο resource που επικοινωνεί με το Kubelet api είναι πάντα οι nodes και το subresource καθορίζεται από το path του εισερχόμενου αιτήματος:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over 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 (που έχει νόημα με τις προηγούμενες πληροφορίες)

Αναφορές

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