Pod Security Standards (PSS) – jak zabezpieczyć kontenery w Kubernetes?

Jednym z największych błędów podczas wdrażania Kubernetes jest przekonanie, że każdy kontener uruchomiony w klastrze jest automatycznie bezpieczny. W rzeczywistości Kubernetes daje ogromną elastyczność – można uruchomić zarówno dobrze zabezpieczoną aplikację, jak i kontener z pełnymi uprawnieniami do hosta.

Aby ograniczyć takie ryzyko, Kubernetes wprowadził Pod Security Standards (PSS) – zestaw standardów definiujących, jakie wymagania bezpieczeństwa powinny spełniać uruchamiane Pody.

PSS nie jest pojedynczą funkcją ani mechanizmem. To zbiór dobrych praktyk, które mogą być egzekwowane przez Pod Security Admission lub inne rozwiązania, takie jak OPA Gatekeeper czy Kyverno.

Dlaczego Pod Security Standards są potrzebne?

Domyślnie kontener może zostać uruchomiony z konfiguracją, która stwarza poważne zagrożenie.

Przykład:

securityContext:
  privileged: true

Taki kontener otrzymuje niemal pełny dostęp do systemu operacyjnego hosta.

Inny przykład:

hostNetwork: true

Aplikacja korzysta bezpośrednio z sieci hosta, omijając izolację zapewnianą przez Kubernetes.

Jeszcze bardziej ryzykowne:

hostPID: true

Kontener może zobaczyć procesy działające na serwerze.

To właśnie przed takimi konfiguracjami mają chronić Pod Security Standards.

Tip eksperta

Jeżeli aplikacja nie wymaga specjalnych uprawnień, przyjmij zasadę:

Każde dodatkowe uprawnienie musi mieć techniczne uzasadnienie.

Trzy poziomy bezpieczeństwa

Pod Security Standards definiują trzy poziomy.

Privileged

↓

Baseline

↓

Restricted

Każdy kolejny poziom jest bardziej restrykcyjny.

Poziom Privileged

To najmniej bezpieczna konfiguracja.

Praktycznie nie nakłada ograniczeń.

Możliwe jest między innymi:

• uruchamianie kontenerów uprzywilejowanych,
• korzystanie z hostPID,
• korzystanie z hostNetwork,
• montowanie katalogów hosta,
• dodawanie capabilities.

Schemat:

Application

↓

Full Host Access

Kiedy stosować?

Tylko w wyjątkowych przypadkach.

Przykłady:

• sterowniki GPU,
• wtyczki sieciowe CNI,
• monitorowanie jądra systemu,
• rozwiązania typu CSI.

Tip eksperta

Jeżeli aplikacja biznesowa wymaga trybu privileged, warto dokładnie przeanalizować jej architekturę. W większości przypadków jest to sygnał, że projekt wymaga zmian.

Poziom Baseline

Baseline eliminuje najbardziej niebezpieczne konfiguracje.

Blokowane są między innymi:

• privileged: true
• większość capabilities
• niektóre typy HostPath
• dostęp do hostPID
• dostęp do hostIPC

Przykład:

securityContext:
  privileged: false

To dobry poziom dla wielu standardowych aplikacji.

Poziom Restricted

Restricted jest obecnie rekomendowanym poziomem dla większości środowisk produkcyjnych.

Wymaga między innymi:

• uruchamiania jako użytkownik non-root,
• wyłączenia eskalacji uprawnień,
• ograniczenia capabilities,
• stosowania Seccomp,
• odpowiednich ustawień SELinux lub AppArmor.

Przykład:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

Tip eksperta

W nowych projektach warto od początku projektować aplikacje zgodnie z poziomem Restricted. Dzięki temu unikniesz późniejszych problemów podczas audytów bezpieczeństwa.

Privileged Containers

Największym zagrożeniem są kontenery uprzywilejowane.

Przykład:

securityContext:
  privileged: true

Schemat:

Container

↓

Linux Kernel

↓

Host Resources

Kontener może:

• ładować moduły jądra,
• zarządzać urządzeniami,
• modyfikować konfigurację hosta.

Run as Non-Root

Jedna z najważniejszych zasad bezpieczeństwa.

Nie:

UID 0

Tak:

UID 1000

Przykład:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000

Dzięki temu nawet przejęcie aplikacji nie daje atakującemu pełnych uprawnień.

Linux Capabilities

Root w systemie Linux posiada wiele możliwości.

Nie każda aplikacja ich potrzebuje.

Przykład:

capabilities:
  drop:
    - ALL

Następnie można dodać tylko wymagane:

capabilities:
  add:
    - NET_BIND_SERVICE

Tip eksperta

Najbezpieczniejszym podejściem jest najpierw usunąć wszystkie capabilities (drop: ALL), a następnie świadomie dodać wyłącznie te niezbędne.

AllowPrivilegeEscalation

Domyślnie proces może próbować zwiększyć swoje uprawnienia.

Wyłączenie tej możliwości:

allowPrivilegeEscalation: false

Skutecznie ogranicza wiele scenariuszy eskalacji uprawnień.

Seccomp

Seccomp ogranicza dostęp do wywołań systemowych jądra Linux.

Przykład:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Korzyści:

• mniej dostępnych syscalli,
• utrudniona eksploatacja podatności,
• lepsza izolacja.

AppArmor i SELinux

PSS współpracuje z mechanizmami Mandatory Access Control.

Najczęściej:

Ubuntu:

AppArmor

Red Hat:

SELinux

Przykład profilu:

Application

↓

AppArmor Profile

↓

Allowed Operations Only

Read-Only Root Filesystem

Jeżeli aplikacja nie musi zapisywać danych w systemie plików:

securityContext:
  readOnlyRootFilesystem: true

Korzyści:

• utrudnione instalowanie malware,
• brak możliwości modyfikacji binariów,
• większa odporność na ransomware.

HostPath Volumes

HostPath umożliwia montowanie katalogów hosta.

Przykład:

volumes:
- hostPath:
    path: /

To bardzo ryzykowna konfiguracja.

Schemat:

Container

↓

Host Filesystem

↓

System Files

W środowiskach produkcyjnych HostPath powinien być używany wyłącznie wtedy, gdy jest absolutnie konieczny.

Host Networking

Przykład:

hostNetwork: true

Kontener otrzymuje dostęp do sieci hosta.

Problemy:

• brak izolacji,
• możliwość konfliktów portów,
• większa powierzchnia ataku.

Pod Security Admission

Od Kubernetes 1.25 mechanizm Pod Security Admission zastąpił PodSecurityPolicy.

Poziom bezpieczeństwa można przypisać do Namespace.

Przykład:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted

Dzięki temu wszystkie nowe Pody muszą spełniać wymagania poziomu Restricted.

Tip eksperta

Dobrą praktyką jest używanie trybu warn lub audit przed włączeniem enforce. Pozwala to wykryć niezgodne konfiguracje bez blokowania wdrożeń.

Przykład bezpiecznego kontenera

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - ALL

Taka konfiguracja spełnia większość wymagań poziomu Restricted.

Typowe błędy

Najczęściej spotykane problemy:

❌ uruchamianie jako root

❌ privileged: true

❌ hostNetwork: true

❌ hostPID: true

❌ pełny dostęp do HostPath

❌ brak Seccomp

❌ pozostawienie wszystkich Linux Capabilities

❌ możliwość eskalacji uprawnień

PSS a DevSecOps

W dojrzałych organizacjach Pod Security Standards są częścią procesu CI/CD.

Schemat:

Developer

↓

Git Repository

↓

CI Pipeline

↓

Security Validation

↓

Pod Security Admission

↓

Production Cluster

Niebezpieczne manifesty są blokowane jeszcze przed wdrożeniem.

Architektura bezpiecznego wdrożenia

Application

↓

Distroless Image

↓

Image Scan

↓

Signed Image

↓

Pod Security Standards

↓

RBAC

↓

Network Policies

↓

Seccomp

↓

AppArmor / SELinux

↓

Kubernetes Cluster

Każda warstwa ogranicza skutki potencjalnego ataku.

Najlepsze praktyki

✅ stosuj poziom Restricted dla większości Namespace’ów

✅ uruchamiaj kontenery jako użytkownik non-root

✅ ustaw allowPrivilegeEscalation: false

✅ używaj RuntimeDefault dla Seccomp

✅ usuwaj wszystkie capabilities i dodawaj tylko niezbędne

✅ włącz readOnlyRootFilesystem, jeśli aplikacja nie zapisuje danych

✅ ogranicz użycie HostPath oraz hostNetwork

✅ testuj zgodność z PSS już w procesie CI/CD

Podsumowanie

Pod Security Standards to jeden z najważniejszych mechanizmów zwiększających bezpieczeństwo Kubernetes. Nie zastępują one RBAC, Network Policies czy skanowania obrazów, ale uzupełniają je, tworząc kolejną warstwę ochrony.

Dobrze zaprojektowany klaster nie opiera bezpieczeństwa na jednym rozwiązaniu. Łączy PSS, Seccomp, AppArmor lub SELinux, RBAC, Network Policies, bezpieczne obrazy kontenerów oraz zasadę Least Privilege. To właśnie takie wielowarstwowe podejście stanowi fundament nowoczesnych środowisk Kubernetes gotowych do pracy w produkcji.

Polecane wpisy

Jak Steam Remote Play umożliwia strumieniowanie gier z jednego komputera na inne urządzenia, takie jak smartfony, tablety i telewizory

Jak Steam Remote Play umożliwia strumieniowanie gier z jednego komputera na inne urządzenia, takie jak smartfony, tablety i telewizory Steam Czytaj dalej

Jak usunąć wirusa i jakich programów do tego użyć

Jak usunąć wirusa i jakich programów do tego użyć Wirusy komputerowe to złośliwe oprogramowanie, które może powodować różne szkody, w Czytaj dalej