Cyber Security Academy · leksjon

RBAC og tjenestekontoer

Sikre tilgangen til klyngen.

Leksjon 2 av 413 trinn

RBAC og tjenestekontoer er en gratis leksjon i Cyber Security Academy på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cyber Security Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cyber Security Academy inneholder totalt 4 leksjoner.

RBAC styrer alt

Role-Based Access Control (RBAC) avgjør hvilke identiteter som kan utføre hvilke handlinger på hvilke ressurser i et cluster. Hvert API-kall blir autorisert mot RBAC. Feilkonfigurert RBAC er den vanligste årsaken til privilegieeskalering inne i et cluster.

  • Subjekter: brukere, grupper og tjenestekontoer.
  • Roller knytter verb til ressurser.
  • Bindinger kobler subjekter til roller.

Roller kontra ClusterRoles

Det finnes to omfang.

  • Role + RoleBinding: tillatelser begrenset til et namespace.
  • ClusterRole + ClusterRoleBinding: tillatelser som gjelder hele clusteret.

En ClusterRoleBinding til cluster-admin gir full kontroll. Å gi den til en tjenestekonto er en vanlig og farlig feil.

Tjenestekontotoken

Hver pod kjører som en tjenestekonto og monterer som standard tokenet til tjenestekontoen. Dette tokenet er en bearer-legitimasjon som gir kontoens RBAC-rettigheter. Hvis poden blir kompromittert, blir tokenet det også.

Moderne clustre utsteder projiserte token med kort levetid og avgrenset målgruppe, men gamle langvarige hemmelighetstoken finnes fortsatt.

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

Kartlegg tillatelsene dine

Etter at du har fått tak i et token, er det første du bør gjøre å finne ut hva det kan brukes til. Kubernetes tilbyr et API for egenkontroll.

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

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

Farlige kombinasjoner av tillatelser

Enkelte verb er primitive for privilegieeskalering, selv uten cluster-admin.

  • create pods: planlegg en privilegert pod eller en hostPath-pod for å bryte deg ut.
  • create pods/exec: kjør kommandoer i eksisterende pods.
  • get/list secrets: les legitimasjoner i hele clusteret.
  • create rolebindings/clusterrolebindings: bind deg selv til admin.
  • escalate / bind-verb: gi deg selv rettigheter du ikke har.
  • impersonate: opptre som et annet, mer privilegert subjekt.

Eskalering via oppretting av pods

Hvis en tjenestekonto kan opprette pods, kan den ofte ta kontroll over noden. Angriperen planlegger en pod som monterer vertens filsystem eller kjører med privilegier, og leser deretter nodelegitimasjoner eller bryter seg ut.

# 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

Eskalering via bindinger

Hvis du kan opprette (cluster)rolebindings, kan du kanskje binde tjenestekontoen din direkte til cluster-admin. Kubernetes beskytter dette med verbene bind/escalate, men feilkonfigurerte roller tillater det noen ganger.

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

Misbruk av impersonation

Verbet impersonate lar et subjekt opptre som en hvilken som helst bruker, gruppe eller tjenestekonto. En principal med omfattende impersonation har i praksis alle tillatelser i clusteret.

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

Revidere RBAC

Forsvarere bør gjennomgå RBAC kontinuerlig for å finne risikable tildelinger.

  • Finn subjekter som er bundet til cluster-admin.
  • Marker jokertegn for verb eller ressurser (*).
  • Oppdag tildelinger som gir ikke-administratorkontoer tilgang til å lese hemmeligheter eller opprette pods.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Sikre tjenestekontoer

Bruk minste privilegium for identiteter.

  • Sett automountServiceAccountToken: false der poden ikke trenger API-tilgang.
  • Gi hver arbeidsbelastning en egen tjenestekonto med minst mulig omfang.
  • Unngå default-tjenestekontoen for reelle arbeidsbelastninger.
  • Bruk projiserte token med kort levetid og angitte målgrupper; roter og bind dem.
  • Bind aldri arbeidsbelastninger til cluster-admin.

Test RBAC på en etisk måte

Ved vurdering av RBAC bør du foretrekke ikke-destruktive kontroller (auth can-i, dry-run) fremfor faktisk å opprette cluster-admin-bindinger i produksjon. Hvis du må bevise eskalering, skal du begrense den til et test-namespace og fjerne alle bindinger eller pods du har opprettet.

Rapporter nøyaktig hvilke roller og bindinger som muliggjorde eskaleringen, slik at de kan strammes inn.

Hurtigsjekk

Kontroller forståelsen din av RBAC.

Oppsummering

Du har lært hvordan RBAC og tjenestekontoer styrer og truer tilgangen til clusteret.

  • RBAC binder subjekter til verb på ressurser; cluster-admin gir full kontroll.
  • Pods monterer SA-token; auth can-i viser rekkevidden deres.
  • create-pods, binding, lesing av hemmeligheter og impersonate er primitive for privilegieeskalering.
  • Tjenestekontoer med minste privilegium og deaktivert automatisk montering sikrer clusteret.

Neste tema: podsikkerhet og nettverkspolicyer.

Gratis å komme i gang

Lær deg Cyber Security Academy med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
76
Leksjoner
303

Ofte stilte spørsmål

Er leksjonen «RBAC og tjenestekontoer» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Cyber Security Academy, inkludert «RBAC og tjenestekontoer», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Cyber Security Academy inneholder totalt 4 leksjoner.

Hva lærer jeg i «RBAC og tjenestekontoer»?

Sikre tilgangen til klyngen. Du øver på Cyber Security Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Cyber Security Academy?

Ingen tidligere erfaring er nødvendig. Cyber Security Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «RBAC og tjenestekontoer»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Cyber Security Academy-leksjonen?

Ja. Alle Cyber Security Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Trusselmodell for Kubernetes
  2. RBAC og tjenestekontoer
  3. Pod-sikkerhet og nettverkspolicyer
  4. Sikring av forsyningskjeden og secrets
← Tilbake til Cyber Security Academy