0Pricing
Cyber Security Academy · Lekcja

RBAC i konta usług

Zabezpieczanie dostępu do klastra

RBAC i konta usług to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

RBAC kontroluje wszystko

Kontrola dostępu oparta na rolach (RBAC) decyduje, które tożsamości mogą wykonywać określone działania na określonych zasobach w klastrze. Każde wywołanie API jest autoryzowane względem RBAC. Błędnie skonfigurowany RBAC jest główną przyczyną eskalacji uprawnień w klastrze.

  • Podmioty: użytkownicy, grupy, konta usług.
  • Role przypisują czasowniki do zasobów.
  • Wiązania łączą podmioty z rolami.

Role a ClusterRole

Istnieją dwa zakresy.

  • Role + RoleBinding: uprawnienia ograniczone do przestrzeni nazw.
  • ClusterRole + ClusterRoleBinding: uprawnienia w całym klastrze.

ClusterRoleBinding do cluster-admin zapewnia pełną kontrolę. Przypisanie go do konta usługi jest częstym i niebezpiecznym błędem.

Tokeny kont usług

Każdy pod działa w kontekście konta usługi i domyślnie ma zamontowany jego token. Ten token jest poświadczeniem typu bearer, które przenosi uprawnienia RBAC konta. Jeśli pod zostanie przejęty, token również.

Nowoczesne klastry wydają projekcjonowane tokeny o krótkim czasie życia, powiązane z odbiorcą, ale starsze tokeny z sekretów o długim czasie życia wciąż pozostają w użyciu.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Sprawdzanie swoich uprawnień

Po przechwyceniu tokenu pierwszym krokiem jest ustalenie, co można za jego pomocą zrobić. Kubernetes udostępnia API do samodzielnego sprawdzania uprawnień.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Niebezpieczne kombinacje uprawnień

Niektóre czasowniki umożliwiają eskalację nawet bez cluster-admin.

  • create pods: zaplanowanie uprzywilejowanego poda lub poda z hostPath w celu ucieczki.
  • create pods/exec: wykonywanie poleceń w istniejących podach.
  • get/list secrets: odczytywanie poświadczeń w całym klastrze.
  • create rolebindings/clusterrolebindings: przypisanie sobie uprawnień administratora.
  • escalate / bind: przyznawanie uprawnień, których się nie posiada.
  • impersonate: działanie jako inny, bardziej uprzywilejowany podmiot.

Eskalacja przez tworzenie podów

Jeśli konto usługi może tworzyć pody, często może przejąć węzeł. Atakujący planuje poda, który montuje system plików hosta lub działa z uprzywilejowaniem, a następnie odczytuje poświadczenia węzła albo ucieka z kontenera.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Eskalacja przez wiązanie uprawnień

Jeśli można tworzyć (cluster)rolebindings, można bezpośrednio przypisać konto usługi do cluster-admin. Kubernetes chroni przed tym za pomocą czasowników bind/escalate, ale błędnie skonfigurowane role czasami na to pozwalają.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Nadużywanie impersonacji

Czasownik impersonate pozwala podmiotowi działać jako dowolny użytkownik, grupa lub konto usługi. Podmiot posiadający szerokie uprawnienia do impersonacji ma w praktyce wszystkie uprawnienia w klastrze.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

Audyt RBAC

Zespoły obrony powinny stale przeglądać RBAC pod kątem ryzykownych nadań uprawnień.

  • Należy znaleźć podmioty przypisane do cluster-admin.
  • Należy oznaczać wieloznaczne czasowniki i zasoby (*).
  • Należy wykrywać nadania uprawnień do odczytu sekretów i tworzenia podów kontom niebędącym administratorami.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Wzmacnianie ochrony kont usług

Należy stosować zasadę najmniejszych uprawnień wobec tożsamości.

  • Należy ustawić automountServiceAccountToken: false tam, gdzie pod nie potrzebuje dostępu do API.
  • Każdemu obciążeniu należy przypisać dedykowane konto usługi o minimalnym zakresie uprawnień.
  • Należy unikać konta usługi default w rzeczywistych obciążeniach.
  • Należy używać projekcjonowanych tokenów o krótkim czasie życia i określonych odbiorcach, a także je rotować i wiązać.
  • Nie wolno przypisywać obciążeń do cluster-admin.

Etyczne testowanie RBAC

Podczas oceny RBAC należy wybierać nieinwazyjne testy (auth can-i, dry-run), zamiast faktycznie tworzyć wiązania cluster-admin na produkcji. Jeśli trzeba udowodnić możliwość eskalacji, należy ograniczyć test do testowej przestrzeni nazw i usunąć wszystkie utworzone wiązania oraz pody.

Należy zgłosić dokładne role i wiązania, które umożliwiły eskalację, aby można było je zaostrzyć.

Szybkie sprawdzenie

Sprawdź swoje rozumienie RBAC.

Podsumowanie

Dowiedziałeś się, jak RBAC i konta usług zarządzają dostępem do klastra oraz jak mogą go zagrozić.

  • RBAC przypisuje podmiotom czasowniki dotyczące zasobów, a cluster-admin zapewnia pełną kontrolę.
  • Pody montują tokeny SA, a auth can-i ujawnia ich zasięg.
  • create-pods, binding, secret-read i impersonate to podstawowe mechanizmy eskalacji.
  • Konta o najmniejszych uprawnieniach i wyłączone automatyczne montowanie wzmacniają ochronę klastra.

Dalej: zabezpieczenia podów i polityki sieciowe.

Często zadawane pytania

Czy lekcja „RBAC i konta usług” jest bezpłatna?

Tak — pełny tekst „RBAC i konta usług” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „RBAC i konta usług”?

Zabezpieczanie dostępu do klastra Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „RBAC i konta usług”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Model zagrożeń Kubernetes
  2. RBAC i konta usług
  3. Bezpieczeństwo podów i zasady sieciowe
  4. Zabezpieczanie łańcucha dostaw i sekretów
← Powrót do Cyber Security Academy