Explain Service Account

Jasne, wyjaśnijmy, czym jest Service Account w Kubernetes w prosty i zrozumiały sposób.

Wyobraź sobie, że Kubernetes to duże biuro. W tym biurze pracują ludzie (administratorzy, deweloperzy) i działają automatyczne maszyny (aplikacje).

• User Account (Konto Użytkownika): To jest tożsamość dla człowieka. Kiedy Ty, jako administrator, łączysz się z klastrem za pomocą kubectl, używasz swojego konta użytkownika, aby się uwierzytelnić.
• Service Account (Konto Usługi): To jest tożsamość dla maszyny/procesu, czyli dla aplikacji działającej wewnątrz Poda. Jest to "dowód osobisty" dla Twojej aplikacji, który pozwala jej udowodnić, kim jest, gdy chce coś zrobić w klastrze.

---

Czym jest Service Account?

Service Account (SA) to tożsamość, którą Kubernetes nadaje procesom uruchomionym wewnątrz Podów. Dzięki niej, procesy te mogą bezpiecznie komunikować się z serwerem API Kubernetesa i wykonywać na nim operacje (np. odczytywać listę innych Podów, tworzyć zasoby itp.).

Dlaczego jest to ważne?

Głównym powodem jest bezpieczeństwo i kontrola dostępu (zasada najmniejszych uprawnień - Principle of Least Privilege).

Zamiast dawać każdej aplikacji pełny dostęp do całego klastra, możemy stworzyć dla niej dedykowany Service Account z bardzo ograniczonymi uprawnieniami. Na przykład:

• Aplikacja do monitoringu może potrzebować tylko uprawnień do odczytu stanu Podów i Węzłów (Nodes).
• Aplikacja do automatycznego wdrażania (CI/CD) może potrzebować uprawnień do tworzenia i aktualizowania zasobów typu Deployment i Service.
• Zwykła aplikacja webowa (np. backend) może w ogóle nie potrzebować dostępu do API Kubernetesa – wtedy jej Service Account nie będzie miał żadnych dodatkowych uprawnień.

---

Jak to działa w praktyce?

Proces jest zautomatyzowany i składa się z kilku kroków:

1. Przypisanie do Poda: Kiedy tworzysz Poda, możesz mu jawnie przypisać konkretny Service Account. Jeśli tego nie zrobisz, Kubernetes automatycznie przypisze mu domyślny SA o nazwie default z danej przestrzeni nazw (Namespace).

2. Montowanie Tokenu: Kubernetes automatycznie tworzy token uwierzytelniający dla tego Service Account i montuje go wewnątrz kontenera Poda w stałej lokalizacji: /var/run/secrets/kubernetes.io/serviceaccount/. W tym katalogu znajdują się pliki takie jak token, ca.crt i namespace.

3. Użycie Tokenu przez Aplikację: Aplikacja działająca w kontenerze (jeśli jest do tego przystosowana, np. przez biblioteki klienckie Kubernetesa) odczytuje ten token.

4. Komunikacja z API: Gdy aplikacja chce wykonać jakąś operację (np. pobrać listę Podów), wysyła żądanie do serwera API Kubernetesa, dołączając odczytany token w nagłówku Authorization.

5. Weryfikacja: Serwer API odbiera żądanie, weryfikuje token, identyfikuje, który Service Account go użył, a następnie sprawdza (za pomocą mechanizmu RBAC), czy ten SA ma uprawnienia do wykonania danej operacji. Jeśli tak – operacja jest dozwolona. Jeśli nie – zwracany jest błąd Forbidden.

---

Główne Komponenty związane z Service Account

Aby w pełni kontrolować dostęp, używa się kombinacji czterech obiektów:

1. ServiceAccount: Sam obiekt tożsamości. Definiuje "kto".

apiVersion: v1
kind: ServiceAccount
metadata:
  name: moja-aplikacja-sa
  namespace: produkcja

2. Role lub ClusterRole: Definiuje zestaw uprawnień ( "co można zrobić").

• Role: Działa w obrębie jednej przestrzeni nazw (Namespace).
• ClusterRole: Działa w obrębie całego klastra.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: czytelnik-podow
  namespace: produkcja
rules:
- apiGroups: [""] # "" oznacza rdzenne API
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

3. RoleBinding lub ClusterRoleBinding: Łączy Service Account z uprawnieniami (Role/ClusterRole). Mówi: "kto" może "co".

• RoleBinding: Łączy SA z Role w tej samej przestrzeni nazw.
• ClusterRoleBinding: Łączy SA z ClusterRole (dając uprawnienia w całym klastrze).

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: przypisz-czytelnika-podow
  namespace: produkcja
subjects:
- kind: ServiceAccount
  name: moja-aplikacja-sa # "Kto"
  namespace: produkcja
roleRef:
  kind: Role
  name: czytelnik-podow # "Co może"
  apiGroup: rbac.authorization.k8s.io

4. Użycie w Podzie:

apiVersion: v1
kind: Pod
metadata:
  name: moja-aplikacja-pod
  namespace: produkcja
spec:
  serviceAccountName: moja-aplikacja-sa # Tutaj przypisujemy SA
  containers:
  - name: moja-aplikacja
    image: nginx

---

Podsumowanie

Pojęcie	Analogia	Opis
Service Account	Dowód osobisty aplikacji	Reprezentuje tożsamość procesu wewnątrz Poda.
Role / ClusterRole	Lista dozwolonych czynności	Definiuje, jakie operacje (np. list, create) można wykonywać na jakich zasobach (np. pods, deployments).
RoleBinding	Przypisanie uprawnień	Łączy tożsamość (Service Account) z listą uprawnień (Role).
Token	Klucz do biura	Sekretny ciąg znaków, którym aplikacja uwierzytelnia się w serwerze API.

W skrócie, Service Account to fundamentalny mechanizm bezpieczeństwa w Kubernetes, który pozwala precyzyjnie kontrolować, co aplikacje działające w klastrze mogą, a czego nie mogą robić.