Kubernetes RBAC i eskalacja uprawnień: techniczny audyt

Kubernetes RBAC kontroluje, jakie operacje uwierzytelniony principal może wykonać przez API klastra. Eskalacja uprawnień pojawia się jednak nie tylko wtedy, gdy użytkownik może utworzyć ClusterRoleBinding do cluster-admin. Równie ważne są prawa do tworzenia workloadów, używania kont ServiceAccount, wykonywania poleceń w Podach, pobierania tokenów, podszywania się pod inne tożsamości i modyfikowania zasobów kontrolowanych przez bardziej uprzywilejowane operatory.

Najkrótsza zasada brzmi: audytuj zdolności, a nie nazwy ról. Rola nazwana developer może pośrednio dawać kontrolę nad całym namespace, a niestandardowa rola z kilkoma czasownikami może otwierać drogę do klastra. Bezpieczny test łączy statyczny graf RBAC, analizę admission control i workloadów oraz minimalny dowód w dedykowanym namespace. Nie wymaga odczytywania produkcyjnych Secretów ani uruchamiania uprzywilejowanego kontenera na węźle.

Jak działa model RBAC w Kubernetes

RBAC opiera się na czterech podstawowych obiektach:

Role definiuje reguły w jednym namespace;
ClusterRole definiuje reguły klastrowe albo zestaw reguł możliwy do powiązania w namespace;
RoleBinding przypisuje rolę podmiotom w konkretnym namespace;
ClusterRoleBinding przypisuje ClusterRole w skali całego klastra.

Reguła wskazuje grupy API, zasoby, opcjonalne nazwy zasobów i czasowniki takie jak get, list, watch, create, update, patch, delete lub czasowniki specjalne. Model jest addytywny: RBAC nie ma ogólnej instrukcji deny. Jeżeli którakolwiek pasująca reguła zezwala na operację, RBAC jej nie odbiera; ograniczenie musi wynikać z braku uprawnienia albo z innej warstwy, na przykład admission policy.

Oficjalna dokumentacja RBAC rozróżnia zasoby namespaced i non-resource URLs. Audyt musi uwzględnić subresources, ponieważ pods, pods/log, pods/exec, pods/attach i pods/portforward są odrębnymi celami autoryzacji. Podobnie serviceaccounts/token nie jest równoważne zwykłemu odczytowi obiektu ServiceAccount.

Dlaczego sama lista `ClusterRoleBinding` nie wystarcza

Efektywna zdolność wynika ze złożenia wielu elementów:

Warstwa	Co trzeba ustalić
Uwierzytelnienie	użytkownik, grupa, ServiceAccount, certyfikat, OIDC lub proxy
Powiązania	wszystkie RoleBinding i ClusterRoleBinding obejmujące principal
Reguły	apiGroups, resources, subresources, verbs i resourceNames
Mutacja	czy principal może zmieniać rolę, binding, webhook lub operatora
Workload	czy może tworzyć Pod/Job/Deployment z wybranym ServiceAccount
Admission	Pod Security, Validating/MutatingAdmissionPolicy i webhooki
Runtime	token, sekrety, wolumeny, capabilities, host access i sieć
Chmura	workload identity i prawa poza klastrem

To graf, nie tabela. Krawędź „może utworzyć Deployment” łączy się z krawędzią „Deployment może użyć uprzywilejowanego ServiceAccount”, chyba że admission lub osobna kontrola to uniemożliwia. Kolejna krawędź może prowadzić do chmurowej roli przypisanej przez workload identity.

Specjalne uprawnienia `escalate`, `bind` i `impersonate`

Kubernetes ma wbudowane zabezpieczenie przed prostym nadaniem sobie praw. Użytkownik nie powinien móc utworzyć lub zmienić Role/ClusterRole zawierającej uprawnienia, których sam nie posiada, chyba że otrzymał czasownik escalate. Analogicznie utworzenie bindingu do roli zwykle wymaga posiadania praw zawartych w roli albo specjalnego bind.

Te zabezpieczenia są skuteczne tylko wtedy, gdy zespoły nie rozdają escalate i bind szeroko. Audyt powinien wskazać każdą rolę mającą te czasowniki, zasoby, których dotyczą, i principal mogący z niej korzystać. Wildcard w verbs lub resources może objąć również zdolności dodane w przyszłości.

impersonate pozwala wysyłać żądania jako inny użytkownik, grupa, ServiceAccount lub dodatkowy atrybut, zależnie od zakresu reguły. Jest potrzebne niektórym komponentom i narzędziom wsparcia, ale stanowi bezpośrednią granicę zaufania. Log audytowy musi zachować zarówno tożsamość pierwotną, jak i impersonowaną.

Eskalacja przez tworzenie workloadów

Dobre praktyki Kubernetes RBAC wyraźnie ostrzegają, że możliwość tworzenia workloadów może prowadzić do dostępu do innych zasobów. Principal tworzący Pod może:

wybrać ServiceAccount, jeżeli admission nie ogranicza tego wyboru;
zamontować dozwolone Secret, ConfigMap i wolumeny;
uruchomić obraz kontrolowany przez siebie;
odziedziczyć dostęp sieciowy namespace;
oddziaływać na inne Pody i usługi;
żądać ustawień hosta lub Linux capabilities, jeśli polityka admission ich nie blokuje.

Dlatego „może tworzyć Deployment” jest uprawnieniem wykonania kodu w danej strefie zaufania, a nie wyłącznie prawem do deklaratywnego YAML. Zdolność ta musi być zestawiona z bezpieczeństwem Kubernetes i kontenerów, Pod Security Standards, politykami sieciowymi i konfiguracją węzłów.

W bezpiecznym teście tworzymy Pod lub Job tylko w dedykowanym namespace, z testowym ServiceAccount o nieszkodliwym prawie. Nie montujemy hostPath, nie używamy host network i nie pobieramy prawdziwych Secretów. Celem jest potwierdzenie, czy admission wymusza zamierzony model.

ServiceAccount i tokeny: najczęstsza granica zaufania

Każdy namespace ma domyślne konto ServiceAccount, ale domyślnie nie powinno ono otrzymywać dodatkowych praw. Workload może używać wskazanego konta, a kubelet udostępnia projekcję krótkotrwałego tokenu, jeżeli montowanie nie zostało wyłączone. Dokumentacja ServiceAccount opisuje TokenRequest API i projekcję tokenów o ograniczonej ważności jako preferowany mechanizm.

Audyt powinien sprawdzić:

które workloady używają default zamiast dedykowanego konta;
gdzie automountServiceAccountToken pozostaje włączone mimo braku potrzeby API;
kto może tworzyć tokeny przez subresource serviceaccounts/token;
czy tokeny mają właściwe audience i czas ważności;
czy istnieją stare, długotrwałe tokeny lub sekrety typu service-account-token;
jakie prawa chmurowe uzyskuje konto przez IRSA, Workload Identity albo odpowiednik dostawcy;
czy użytkownik może wybrać mocniejsze konto podczas tworzenia workloadu.

Rotacja tokenu nie naprawia zbyt szerokiej roli. Najpierw usuwa się niepotrzebne bindingi i ścieżkę wyboru tożsamości, a następnie obraca poświadczenia zgodnie z procesem zarządzania sekretami.

Subresources, które zmieniają ocenę ryzyka

Prawo do pods/exec lub pods/attach oznacza możliwość wejścia do działającego kontenera. W praktyce może ujawnić zmienne środowiskowe, token, pliki konfiguracyjne i łączność Poda. pods/portforward może ominąć część założeń o ekspozycji usługi, choć nadal podlega autoryzacji API i jest obserwowalne. pods/log może zawierać sekrety, dane klientów lub tokeny omyłkowo zapisane przez aplikację.

Podobnie ryzykowne są prawa do:

aktualizacji deployments, daemonsets, statefulsets, jobs i cronjobs;
modyfikacji mutatingwebhookconfigurations i validatingwebhookconfigurations;
tworzenia certificatesigningrequests i zatwierdzania wybranych signerów;
zmiany nodes/proxy, zasobów operatorów i niestandardowych CRD;
odczytu lub zmiany secrets;
patchowania statusu lub finalizerów, jeśli kontroler ufa tym polom.

Nie każda instalacja ma te same operatory. CRD może reprezentować bazę, bucket, użytkownika albo politykę chmurową. Audyt RBAC musi więc poznać semantykę zasobu, a nie traktować wszystkich CRD jako nieszkodliwego YAML.

Agregowane ClusterRole i zmiany w czasie

Kubernetes potrafi budować ClusterRole przez agregację innych ról oznaczonych odpowiednimi etykietami. To przydatne dla rozszerzeń, ale tworzy zależność: dodanie etykietowanej roli może automatycznie poszerzyć rolę agregowaną, na przykład używaną przez wielu developerów. Zespół powinien monitorować role z aggregationRule, uprawnienia do tworzenia lub etykietowania ClusterRole oraz zmiany wprowadzane przez Helm i operatorów.

Wbudowane role i bindingi oznaczone kubernetes.io/bootstrapping=rbac-defaults mogą podlegać auto-reconciliation przy starcie API servera. Nie należy naprawiać modelu przez przypadkową edycję obiektów systemowych bez zrozumienia zachowania aktualizacji.

Bezpieczna metodologia audytu i pentestu RBAC

1. Ustal granice i tenantów

Dokumentujemy klastry, konteksty, dystrybucje, namespaces, administratorów, workload identity, systemy wyłączone i dozwolone operacje. Namespace nie jest automatycznie twardą granicą wielodzierżawności. Jeśli różni tenantci nie ufają sobie, trzeba ocenić węzły, sieć, admission, storage i operatorów.

2. Zbuduj graf efektywnych uprawnień

Zbieramy Role, ClusterRole, bindingi, ServiceAccount, agregacje oraz konfigurację uwierzytelnienia. SelfSubjectAccessReview i SelfSubjectRulesReview pomagają potwierdzić widok konkretnej tożsamości, ale dokumentacja zaznacza ograniczenia reguł wynikowych. Ostateczny graf musi uwzględniać możliwość zmiany obiektów i uruchamiania workloadów.

3. Sklasyfikuj zdolności wysokiego ryzyka

Priorytet otrzymują cluster-admin, system:masters, wildcardy, bind, escalate, impersonate, sekrety, tokeny, CSR, webhooki, węzły, exec/attach/port-forward oraz tworzenie workloadów z dowolnym ServiceAccount. Oddzielamy zdolność bezpośrednią od warunkowej.

4. Zweryfikuj admission w namespace testowym

Tworzymy testowe Role i ServiceAccount oraz harmless workloads. Sprawdzamy, czy niedozwolony wybór konta, securityContext lub wolumenu jest odrzucany. Nie testujemy ucieczki na produkcyjnym węźle. Test ma pokazać decyzję API i odpowiedni log, nie przejęcie hosta.

5. Retestuj po usunięciu całej ścieżki

Po poprawce sprawdzamy RBAC, admission, workload i chmurową tożsamość. Usunięcie jednego bindingu nie pomaga, jeżeli ten sam principal należy do grupy z równoważną rolą albo może utworzyć nowy binding przez operatora.

W klastrach zarządzanych retest powinien wejść w szerszy pentest chmury AWS, Azure lub GCP, ponieważ tożsamość workloadu, panel dostawcy i role control plane mogą rozszerzać graf poza API Kubernetes.

Audit logs i detekcja eskalacji

Kubernetes auditing zapisuje chronologiczny zestaw zdarzeń API. Polityka audytu powinna obejmować metadane lub treść odpowiednich zmian, przy jednoczesnym unikaniu logowania wrażliwych danych żądań. Logi muszą trafiać poza klaster lub do chronionego backendu.

Wysokowartościowe zdarzenia to:

create/update/patch Role, ClusterRole, RoleBinding i ClusterRoleBinding;
użycie bind, escalate lub impersonation;
TokenRequest dla ServiceAccount poza normalnym workloadem;
utworzenie Poda z uprzywilejowanym securityContext, host namespaces albo hostPath;
pods/exec, attach i portforward wykonywane przez nietypowy principal;
zmiana admission webhooka, polityki lub namespace labels Pod Security;
utworzenie lub zatwierdzenie CSR;
nagły wzrost Forbidden, po którym następuje skuteczna operacja uprzywilejowana.

Korelacja powinna łączyć użytkownika, grupy, source IP, user agent, impersonation i późniejsze akcje nowej tożsamości. Incident response obejmuje unieważnienie poświadczeń źródłowych, usunięcie nieautoryzowanych bindingów, przegląd workloadów i rotację osiągalnych sekretów.

Hardening Kubernetes RBAC

Nadawaj prawa w namespace, a ClusterRoleBinding traktuj jako wyjątek.
Twórz dedykowane ServiceAccount dla workloadów i wyłączaj automount tam, gdzie API nie jest potrzebne.
Unikaj wildcardów w zasobach i czasownikach, szczególnie dla CRD.
Ogranicz bind, escalate i impersonate do kontrolowanych komponentów.
Oddziel osobę wdrażającą workload od osoby nadającej jego ServiceAccount.
Wymuszaj Pod Security Standards i dodatkowe polityki admission dla kont, obrazów oraz wolumenów.
Ogranicz exec/attach/port-forward, a sesje administracyjne audytuj.
Skanuj obrazy i podpisy zgodnie z procesem bezpieczeństwa obrazów kontenerów.
Ogranicz sieć workloadów, ponieważ RBAC nie kontroluje połączeń bezpośrednich między Podami.
Po krytycznych advisory, takich jak IngressNightmare CVE-2025-1974, oceniaj także prawa przejętego kontrolera.