0Pricing
DevOps Bootcamp · Lekcja

Standardy bezpieczeństwa Podów

Stosuj standardy bezpieczeństwa Podów, aby egzekwować najlepsze praktyki bezpieczeństwa na poziomie Poda.

Standardy bezpieczeństwa Podów to bezpłatna lekcja DevOps Bootcamp na CoddyKit. To lekcja 3 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 DevOps Bootcamp, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Czym są PSS?

Standardy bezpieczeństwa podów Kubernetes (PSS) to zestaw wytycznych i mechanizmów służących do egzekwowania najlepszych praktyk bezpieczeństwa w podach.

Pomagają chronić klaster przed typowymi lukami w zabezpieczeniach i atakami polegającymi na eskalacji uprawnień, ograniczając możliwości podów.

Można traktować je jak listę kontrolną bezpieczeństwa dla podów!

Trzy poziomy bezpieczeństwa

PSS definiuje trzy odrębne poziomy bezpieczeństwa, z których każdy zapewnia inny stopień ochrony:

  • Privileged: bez ograniczeń, najmniej bezpieczny.
  • Baseline: zapobiega znanym sposobom eskalacji uprawnień.
  • Restricted: wymusza zaostrzone najlepsze praktyki bezpieczeństwa.

Poziomy te są kumulatywne, co oznacza, że Restricted obejmuje wszystkie zabezpieczenia Baseline, a Baseline obejmuje wszystkie zabezpieczenia Privileged (a właściwie ich brak).

Privileged: dostęp bez ograniczeń

Poziom PSS Privileged zapewnia politykę bezpieczeństwa bez ograniczeń.

Oznacza to, że pody działające w ramach tej polityki mogą żądać dowolnych możliwości i uzyskiwać pełny dostęp do zasobów oraz przestrzeni nazw hosta, podobnie jak proces uruchomiony jako root na komputerze hosta.

Ten poziom jest ogólnie uznawany za bardzo niebezpieczny i powinien być używany wyłącznie w przypadku obciążeń systemowych, które bezwzględnie wymagają takiego dostępu.

Baseline: zapobieganie exploitom

Poziom PSS Baseline ma na celu zapobieganie znanym sposobom eskalacji uprawnień.

To dobry punkt wyjścia dla większości aplikacji definiowanych przez użytkownika.

Najważniejsze ograniczenia obejmują:

  • Brak kontenerów uprzywilejowanych.
  • Brak woluminów hostPath (z wyjątkiem określonych bezpiecznych typów).
  • Brak współdzielenia sieci hosta ani przestrzeni nazw PID.
  • Ograniczone możliwości.

Ten poziom pomaga ograniczyć wiele typowych wektorów ataku.

Restricted: zaostrzone bezpieczeństwo

Poziom PSS Restricted wymusza zaostrzone najlepsze praktyki bezpieczeństwa.

Jest przeznaczony dla aplikacji o szczególnie wysokich wymaganiach bezpieczeństwa i wymaga uruchamiania podów z minimalnymi uprawnieniami.

Oprócz ograniczeń poziomu Baseline, Restricted wymusza:

  • Uruchamianie jako użytkownik inny niż root.
  • Usunięcie wszystkich możliwości systemu Linux i dodanie wyłącznie tych, które są wymagane.
  • Wymaganie profili seccomp i AppArmor.

To najbardziej bezpieczny i najbardziej restrykcyjny poziom PSS.

Wymuszanie PSS za pomocą Admission

Standardy bezpieczeństwa Podów są wymuszane za pomocą funkcji Kubernetes o nazwie Pod Security Admission.

Ten kontroler admission przechwytuje żądania tworzenia Podów i sprawdza je pod kątem poziomu PSS skonfigurowanego dla przestrzeni nazw Poda.

Poziomy PSS stosuje się do przestrzeni nazw, dodając do nich określone etykiety. Na przykład:

kubectl label namespace <namespace-name> pod-security.kubernetes.io/enforce=restricted

Kontrolowanie bezpieczeństwa Podów

Aby zapewnić zgodność Podów z PSS, często używa się pola securityContext w definicji Poda.

To pole umożliwia zdefiniowanie ustawień uprawnień i kontroli dostępu dla Poda lub poszczególnych kontenerów w jego obrębie.

Typowe ustawienia obejmują:

  • runAsUser: określa identyfikator użytkownika procesu kontenera.
  • allowPrivilegeEscalation: uniemożliwia procesowi uzyskanie większych uprawnień niż jego proces nadrzędny.
  • capabilities: zarządza capabilities systemu Linux.

Przykład niezabezpieczonego Poda

Przyjrzyjmy się definicji Poda, która narusza standard PSS na poziomie Baseline ze względu na swój kontekst bezpieczeństwa. Taka konfiguracja jest ogólnie niebezpieczna:

apiVersion: v1
kind: Pod
metadata:
  name: unsafe-pod
spec:
  containers:
  - name: my-container
    image: nginx
    securityContext:
      privileged: true
      # This allows the container to run with root capabilities
      # and access host devices directly.
      # Violates Baseline PSS.

Przykład Poda zgodnego z Baseline

Tak można zdefiniować Poda zgodnego z poziomem PSS Baseline. Proszę zwrócić uwagę na brak privileged: true i innych ograniczeń.

Aby uzyskać jeszcze bardziej rygorystyczną zgodność z poziomem Restricted, należy dodać runAsNonRoot: true, readOnlyRootFilesystem: true oraz usunąć wszystkie capabilities.

apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  containers:
  - name: my-container
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      # This Pod runs with minimal privileges and
      # adheres to the Baseline PSS.

Szybkie sprawdzenie PSS

Które z poniższych stwierdzeń dotyczących standardów bezpieczeństwa Podów (PSS) jest PRAWDZIWE?

Podsumowanie: standardy bezpieczeństwa Podów

W tej lekcji poznali Państwo standardy bezpieczeństwa Podów Kubernetes (PSS) oraz ich znaczenie dla zabezpieczania klastra.

  • PSS definiują trzy poziomy: Privileged, Baseline i Restricted.
  • Baseline zapobiega znanym sposobom eskalacji uprawnień i jest odpowiedni dla większości aplikacji.
  • Restricted wymusza zaostrzone zabezpieczenia i wymaga minimalnych uprawnień.
  • Pole securityContext pomaga konfigurować Pody tak, aby były zgodne z PSS.

Stosowanie PSS to kluczowy krok w tworzeniu bezpieczniejszych środowisk Kubernetes!

Często zadawane pytania

Czy lekcja „Standardy bezpieczeństwa Podów” jest bezpłatna?

Tak — pełny tekst „Standardy bezpieczeństwa Podów” 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 DevOps Bootcamp, przejdź na CoddyKit PRO. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Co nauczysz się w „Standardy bezpieczeństwa Podów”?

Stosuj standardy bezpieczeństwa Podów, aby egzekwować najlepsze praktyki bezpieczeństwa na poziomie Poda. Ćwiczysz DevOps Bootcamp 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ąć DevOps Bootcamp?

Nie wymagamy żadnego doświadczenia. DevOps Bootcamp 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 3 z 4.

Ile czasu zajmuje lekcja „Standardy bezpieczeństwa Podów”?

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 DevOps Bootcamp?

Tak. Każda lekcja DevOps Bootcamp 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

  1. Kontrola dostępu oparta na rolach (RBAC)
  2. Network Policies zapewniające izolację
  3. Standardy bezpieczeństwa Podów
  4. Konta usług i tożsamość obciążeń
← Powrót do DevOps Bootcamp