Mówiąc o sferze IT, opisując nowe technologie przychodzi zawsze ten moment, kiedy należy sobie powiedzieć o bezpieczeństwie. Wiemy czym jest Kubernetes, jak go używać, stosować i do czego, to czas powiedzieć kilka słów o bezpieczeństwie. Kubernetes, jako platforma rejestrująca setki aplikacji i usług, stanowi krytyczny element infrastruktury, który wymaga wielowarstwowego podejścia do bezpieczeństwa. W przeciwieństwie do tradycyjnych środowisk, gdzie fizyczna izolacja zapewniała podstawową ochronę, architektura mikroserwisowa i wielodostępność klastra wymuszają przyjęcie założeń modelu „Zero Trust” – „nigdy nie ufaj, zawsze weryfikuj”.

Bezpieczeństwo w Kubernetes nie jest pojedynczym elementem, ale ciągłym procesem obejmującym authentication, authorization, encryption, i network policies. W tym kontekście, zrozumienie mechanizmów kontroli dostępu opartych na rolach (RBAC), właściwe zarządzanie tożsamościami usług (Service Accounts) oraz świadomość najczęstszych błędów konfiguracyjnych stanowią pożądane umiejętności dla każdego administratora i architekta, pragnącego zapewnić integralność i poufność danych oraz ciągłość działania usług w środowisku produkcyjnym.

1. RBAC (Role-Based Access Control) – Kontrola Dostępu Oparta na Rolach

RBAC to system kontroli dostępu w Kubernetes, który decyduje kto może wykonać jakie akcje na jakich zasobach w klastrze.
Jest to mechanizm oparty na rolach – zamiast przypisywać prawa bezpośrednio użytkownikom lub aplikacjom, tworzymy role z określonymi uprawnieniami, a następnie przypisujemy je do kont (userów, Service Accounts).

Główne funkcje RBAC

  1. Autoryzacja – RBAC odpowiada za to, czy dana tożsamość (np. użytkownik lub aplikacja) może wykonać żądanie wobec API Servera.
  2. Granularność – pozwala precyzyjnie definiować uprawnienia: od pełnego dostępu do całego klastra, aż po bardzo ograniczone uprawnienia tylko do odczytu w jednym namespace.
  3. Separacja obowiązków – różne role dla developerów, administratorów, aplikacji czy systemów CI/CD.
  4. Zasada najmniejszych uprawnień (Least Privilege) – każda tożsamość dostaje tylko te prawa, które są absolutnie potrzebne.

Główne obiekty RBAC

a) Role – Obowiązują w ramach pojedynczego namespace’a. Używane do przyznawania dostępu do zasobów wewnątrz danego namespace (np. dev, production).

Przykładowy plik z rolami .yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: dev

  name: pod-reader

rules:

– apiGroups: [„”]

  resources: [„pods”]

  verbs: [„get”, „watch”, „list”]

b) ClusterRole – zbiór uprawnień globalnych dla całego klastra (np. „może odczytać wszystkie Pody we wszystkich namespace’ach”).

Przykładowy plik .yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]

c) RoleBinding – przypisanie roli do użytkownika lub Service Account w konkretnym namespace.

Przykładowy plik .yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods
subjects: 
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef: 
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

d) ClusterRoleBinding – przypisanie ClusterRole globalnie, niezależnie od namespace.

Przykładowy plik .yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes-global
subjects:
- kind: Group
  name: system:authenticated użytkowników
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

e) Namespaces: Chociaż nie są stricte mechanizmem RBAC, są jego nierozłącznym elementem. Stanowią granicę izolacji dla zasobów i polityk RBAC. Dzieląc klaster na logiczne segmenty (np. dev, staging, prod), minimalizujemy efekt „eskalacji” – podmiot z uprawnieniami w namespace dev nie będzie miał do nich dostępu w prod, chyba że jawnie mu je przyznamy.

Schemat działania:

2. Service Accounts: Tożsamość dla Podów

Pod, w przeciwieństwie do użytkownika, nie loguje się do systemu. Aby komunikować się z API Kubernetes (np. odczytać Secret, sprawdzić status innego Pod-a), potrzebuje tożsamości. Tą tożsamością jest Service Account zwany w skrócie SA.

  1. Domyślny Service Account: Każdy namespace ma domyślny Service Account o nazwie default. Jeśli nie wskażesz innego, Pod zostanie uruchomiony z tym kontem, które zwykle ma bardzo ograniczone uprawnienia (lub żadne).
  2. Tworzenie Dedykowanych Service Accounts: Dla każdej aplikacji należy stworzyć dedykowane Service Account i przyznać mu minimalne, niezbędne uprawnienia (Zasada Najmniejszych Uprawnień).
  3. Przypisywanie Service Account do Podów: W manifeście Pod definiuje się, którego konta używać.
  4. Tokeny i Secrets: Kubernetes automatycznie tworzy Secret przechowujący token JWT dla Service Account. Ten token jest montowany do Pod-a pod ścieżką /var/run/secrets/kubernetes.io/serviceaccount/token i jest używany do uwierzytelniania przy API.

Przepływ żądań API z SA

3. Najczęstsze Błędy Bezpieczeństwa i Luki

Mimo, że Kubernetes oferuje zaawansowane i solidne mechanizmy bezpieczeństwa, ich prawidłowa konfiguracja i utrzymanie pozostają wyzwaniem nawet dla doświadczonych adminów. Praktyka oraz raporty bezpieczeństwa, takie jak coroczny Kubernetes Security Report, konsekwentnie wskazują, że zdecydowana większość incydentów nie wynika z nowych, zero-day’owych podatności, lecz z powtarzających się, dobrze znanych błędów konfiguracyjnych i złych praktyk wdrożeniowych. Zrozumienie tych najczęstszych pułapek jest ważne by budować proaktywną kulturę bezpieczeństwa. Omówimy konkretne, często spotykane luki, które atakujący chętnie wykorzystują, a które można zmitygować dzięki odpowiedniej wiedzy i podejściu.

a) Nadmiernie/Permisywne Uprawnienia Service Accounts: Najczęstszy i najpoważniejszy błąd. Nadawanie Podom uprawnień cluster-admin lub przyznawanie wszystkim Service Accounts w namespace uprawnień do odczytu Secretów.

Co robić? Stosowanie Zasady Najmniejszych Uprawnień. Używanie kubectl auth can-i –as=system:serviceaccount:<ns>:<sa> <verb> <resource> do testowania uprawnień.

b) Używanie Domyślnego Service Account: Pozostawienie Podów uruchomionych na default Service Account, który może być podatny na eskalację uprawnień jeśli nie jest odpowiednio zabezpieczony.

Co robić? Zawsze tworzyć dedicated Service Accounts dla aplikacji.

c) Niezabezpieczony Dashboard Kubernetes: Wystawienie Dashboard UI na publiczny Internet bez odpowiedniego uwierzytelniania (np. tylko po kubectl proxy) jest otwarciem furtki do ataku.

Jak zabezpieczyć? Użycie Ingress z uwierzytelnianiem, VPN lub innej formy kontroli dostępu. W drugiej części było wystawianie tylko na pokaz, ale nie pokazaliśmy jak, bo to miało tylko zobrazować, że działa, ale nie powinno się wystawiać tak publicznie serwisów.

d) Przechowywanie haseł (Secrets) czystym tekstem: Umieszczanie haseł, tokenów w ConfigMapach zamiast w Secrets lub nawet committowanie ich do repozytorium Git.

Jak przechowywać? Używanie zasobów Secret, szyfrowanie etc., użycie zewnętrznych kontenerów, np. chmurowych (HashiCorp Vault, AWS Secrets Manager).

e) Brak Network Policies: Pozwalanie wszystkim Podom na komunikację ze wszystkimi innymi Podami (default-allow-all).

Jak zabezpieczyć? Definiowanie Network Policies, które zezwalają tylko na niezbędną komunikację (np. frontend może rozmawiać tylko z backendem na porcie 80).

4. Podsumowanie

Podsumowując należy zdać sobie sprawę, że budowanie bezpiecznego klastra Kubernetes to inwestycja w wiele warstw kontroli – od starannie zaprojektowanego RBAC i izolacji namespace’ów, przez świadome zarządzanie tożsamościami kont usług, po proaktywne wyszukiwanie i eliminowanie najczęstszych błędów konfiguracyjnych. Zrozumienie tych mechanizmów jest niezbędne do zapewnienia odporności i zaufania do środowiska produkcyjnego. Bezpieczeństwo w Kubernetes nie polega tylko na instalacji klastra – to ciągły proces konfiguracji i monitoringu. RBAC i Service Accounts pozwalają dokładnie zdefiniować, kto i co może robić w systemie, a namespaces zapewniają izolację środowisk. Najczęstsze błędy wynikają z wygody i przyzwyczajenia, jak nadawanie za dużych uprawnień, brak separacji, uruchamianie kontenerów jako root. Dobre praktyki to zasada najmniejszych uprawnień (Least Privilege), oddzielanie środowisk namespace’ami, stosowanie Service Accounts z ograniczonymi rolami oraz regularne audyty uprawnień.