Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Το Kubernetes έχει ένα module εξουσιοδότησης που ονομάζεται Role-Based Access Control (RBAC) που βοηθά στη ρύθμιση των δικαιωμάτων χρήσης στον API server.
Το μοντέλο δικαιωμάτων του RBAC είναι δομημένο από τρία ξεχωριστά μέρη:
Subject (Χρήστης, Ομάδα ή ServiceAccount) – Το αντικείμενο που θα λάβει τα δικαιώματα.
RoleBinding\ClusterRoleBinding – Η σύνδεση μεταξύ Role\ClusterRole και του υποκειμένου.
Η διαφορά μεταξύ “Roles” και “ClusterRoles” είναι απλώς το πού θα εφαρμοστεί ο ρόλος – μια “Role” θα παραχωρήσει πρόσβαση μόνο σε ένα συγκεκριμένο namespace, ενώ μια “ClusterRole” μπορεί να χρησιμοποιηθεί σε όλα τα namespaces στο cluster. Επιπλέον, οι ClusterRoles μπορούν επίσης να παραχωρήσουν πρόσβαση σε:
cluster-scoped πόρους (όπως οι κόμβοι).
non-resource endpoints (όπως το /healthz).
πόρους με namespace (όπως τα Pods), σε όλα τα namespaces.
Από το Kubernetes 1.6 και μετά, οι πολιτικές RBAC είναι ενεργοποιημένες από προεπιλογή. Αλλά για να ενεργοποιήσετε το RBAC μπορείτε να χρησιμοποιήσετε κάτι όπως:
Στο πρότυπο ενός Role ή ενός ClusterRole θα χρειαστεί να υποδείξετε το όνομα του ρόλου, το namespace (σε ρόλους) και στη συνέχεια τις apiGroups, resources και verbs του ρόλου:
Οι apiGroups είναι ένας πίνακας που περιέχει τα διάφορα API namespaces στα οποία ισχύει αυτός ο κανόνας. Για παράδειγμα, μια ορισμός Pod χρησιμοποιεί apiVersion: v1. Μπορεί να έχει τιμές όπως rbac.authorization.k8s.io ή [*].
Οι resources είναι ένας πίνακας που ορίζει ποιοι πόροι ισχύουν για αυτόν τον κανόνα. Μπορείτε να βρείτε όλους τους πόρους με: kubectl api-resources --namespaced=true
Οι verbs είναι ένας πίνακας που περιέχει τα επιτρεπόμενα ρήματα. Το ρήμα στο Kubernetes ορίζει τον τύπο ενέργειας που πρέπει να εφαρμόσετε στον πόρο. Για παράδειγμα, το ρήμα list χρησιμοποιείται κατά συλλογών ενώ το "get" χρησιμοποιείται κατά ενός μεμονωμένου πόρου.
(Αυτές οι πληροφορίες ελήφθησαν από the docs)
POST
create
GET, HEAD
get (για μεμονωμένους πόρους), list (για συλλογές, συμπεριλαμβανομένου του πλήρους περιεχομένου αντικειμένων), watch (για παρακολούθηση ενός μεμονωμένου πόρου ή συλλογής πόρων)
PUT
update
PATCH
patch
DELETE
delete (για μεμονωμένους πόρους), deletecollection (για συλλογές)
Το Kubernetes μερικές φορές ελέγχει την εξουσιοδότηση για πρόσθετες άδειες χρησιμοποιώντας εξειδικευμένα ρήματα. Για παράδειγμα:
use
ρήμα στους πόρους podsecuritypolicies
στην ομάδα API policy
.
bind
και escalate
ρήματα στους πόρους roles
και clusterroles
στην ομάδα API rbac.authorization.k8s.io
.
impersonate
ρήμα στους users
, groups
, και serviceaccounts
στην κύρια ομάδα API, και το userextras
στην ομάδα API authentication.k8s.io
.
Μπορείτε να βρείτε όλα τα ρήματα που υποστηρίζει κάθε πόρος εκτελώντας kubectl api-resources --sort-by name -o wide
Για παράδειγμα, μπορείτε να χρησιμοποιήσετε ένα ClusterRole για να επιτρέψετε σε έναν συγκεκριμένο χρήστη να εκτελεί:
Από τα έγγραφα: Ένα role binding παραχωρεί τις άδειες που ορίζονται σε έναν ρόλο σε έναν χρήστη ή σε ένα σύνολο χρηστών. Περιέχει μια λίστα υποκειμένων (χρηστών, ομάδων ή λογαριασμών υπηρεσιών) και μια αναφορά στον ρόλο που παραχωρείται. Ένα RoleBinding παραχωρεί άδειες εντός ενός συγκεκριμένου namespace ενώ ένα ClusterRoleBinding παραχωρεί αυτή την πρόσβαση σε επίπεδο cluster.
Οι άδειες είναι προσθετικές οπότε αν έχετε ένα clusterRole με “list” και “delete” μυστικά μπορείτε να το προσθέσετε με ένα Role με “get”. Οπότε να είστε προσεκτικοί και να δοκιμάζετε πάντα τους ρόλους και τις άδειές σας και να καθορίζετε τι είναι ΕΠΙΤΡΕΠΤΟ, γιατί τα πάντα είναι ΑΠΑΓΟΡΕΥΜΕΝΑ από προεπιλογή.
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)