Kubernetes Basics · Lekcja

Konta usług i tożsamość obciążeń

Dowiedz się, jak Service Accounts nadają Podom własną tożsamość, jak działają ich tokeny oraz jak przyznawać im dostęp zgodny z zasadą najmniejszych uprawnień.

Konta usług i tożsamość obciążeń to bezpłatna lekcja Kubernetes Basics na CoddyKit. To lekcja 4 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 Kubernetes Basics, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Kubernetes Basics zawiera 4 lekcji w sumie.

Tożsamość obciążeń

Użytkownicy uwierzytelniają się w Kubernetesie, ale Pody również potrzebują tożsamości, aby bezpiecznie komunikować się z serwerem API. Tą tożsamością jest konto usługi.

Czym jest konto usługi

ServiceAccount to obiekt należący do przestrzeni nazw, reprezentujący tożsamość obciążenia. Każdy Pod działa w kontekście jednego konta, a jeśli go nie określisz, użyje konta default.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: report-generator
  namespace: analytics

Przypisywanie konta usługi do Poda

Ustaw serviceAccountName w specyfikacji Poda, aby uruchomić go z określoną tożsamością.

apiVersion: v1
kind: Pod
metadata:
  name: reporter
spec:
  serviceAccountName: report-generator
  containers:
  - name: app
    image: reporter:1.0

Montowany token

Kubernetes montuje w Podzie krótkotrwały token JWT konta usługi, który służy do uwierzytelniania wywołań API.

# inside the Pod
cat /var/run/secrets/kubernetes.io/serviceaccount/token

Dlaczego konto domyślne jest ryzykowne

Konto usługi default jest współdzielone przez wszystkie Pody w przestrzeni nazw. Nadanie mu uprawnień naraziłoby wszystko na nadmierny dostęp. Zaleca się używanie osobnego konta dla każdego obciążenia.

Wyłączanie automatycznego montowania tokenu

Jeśli Pod nigdy nie wywołuje API, wyłącz montowanie tokenu, aby zmniejszyć powierzchnię ataku.

apiVersion: v1
kind: Pod
metadata:
  name: no-api-pod
spec:
  automountServiceAccountToken: false
  containers:
  - name: app
    image: myapp:1.0

Nadawanie uprawnień za pomocą RBAC

Konto usługi nie ma żadnych uprawnień, dopóki nie powiążesz go z Role. Podmiotem RoleBinding jest konto usługi.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: reporter-read
  namespace: analytics
subjects:
- kind: ServiceAccount
  name: report-generator
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Najmniejsze uprawnienia w praktyce

Jedno konto usługi dla każdego obciążenia
Nadawaj tylko te czasowniki i zasoby, których obciążenie rzeczywiście potrzebuje
W miarę możliwości ograniczaj zakres do przestrzeni nazw za pomocą Role, a nie ClusterRole

Powiązane, projekcjonowane tokeny

Współczesne tokeny są projekcjonowane i powiązane z czasem życia Poda, a także mają krótki czas wygaśnięcia. Automatycznie się rotują, dlatego wyciek tokenu jest znacznie mniej niebezpieczny niż w przypadku dawnych długotrwałych sekretów.

Tożsamość obciążenia w chmurze

Platformy chmurowe mapują Kubernetesowy ServiceAccount na tożsamość IAM w chmurze, na przykład IRSA w AWS lub Workload Identity w GKE, dzięki czemu Pody uzyskują dostęp do zasobów chmurowych bez przechowywania statycznych poświadczeń.

metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123:role/report-role

Weryfikowanie uprawnień

Użyj kubectl auth can-i z personifikacją konta usługi, aby potwierdzić, że ma ono dokładnie taki dostęp, jakiego oczekujesz.

kubectl auth can-i list pods \
  --as=system:serviceaccount:analytics:report-generator \
  -n analytics

Szybkie sprawdzenie

Sprawdź swoje rozumienie kont usług.

Podsumowanie

Dowiedziałeś się, że ServiceAccount nadaje Podowi własną tożsamość wspieraną przez krótkotrwałe projekcjonowane tokeny. Stosuj zasadę najmniejszych uprawnień, używając osobnego konta dla każdego obciążenia, nadawaj dostęp za pomocą powiązań RBAC, wyłączaj nieużywane montowanie tokenów i mapuj konta na tożsamości IAM w chmurze, aby uzyskać dostęp bez poświadczeń.

Często zadawane pytania

Czy lekcja „Konta usług i tożsamość obciążeń” jest bezpłatna?

Tak — pełny tekst „Konta usług i tożsamość obciążeń” 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 Kubernetes Basics, przejdź na CoddyKit PRO. Kurs Kubernetes Basics zawiera 4 lekcji w sumie.

Co nauczysz się w „Konta usług i tożsamość obciążeń”?

Dowiedz się, jak Service Accounts nadają Podom własną tożsamość, jak działają ich tokeny oraz jak przyznawać im dostęp zgodny z zasadą najmniejszych uprawnień. Ćwiczysz Kubernetes Basics 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ąć Kubernetes Basics?

Nie wymagamy żadnego doświadczenia. Kubernetes Basics 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 4 z 4.

Ile czasu zajmuje lekcja „Konta usług i tożsamość obciążeń”?

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 Kubernetes Basics?

Tak. Każda lekcja Kubernetes Basics 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

Kontrola dostępu oparta na rolach (RBAC)
Network Policies zapewniające izolację
Standardy bezpieczeństwa Podów
Konta usług i tożsamość obciążeń

← Powrót do Kubernetes Basics