Admission Controllers w Kubernetes – ostatnia linia obrony przed wdrożeniem niebezpiecznych zasobów

Kubernetes posiada rozbudowany mechanizm autoryzacji i kontroli dostępu, jednak nawet poprawnie uwierzytelniony użytkownik z odpowiednimi uprawnieniami może przypadkowo lub celowo wdrożyć niebezpieczną konfigurację.

Przykład:

apiVersion: v1
kind: Pod

spec:

  containers:
  - name: app
    image: nginx

    securityContext:
      privileged: true

Jeżeli użytkownik posiada odpowiednie uprawnienia RBAC, taki Pod zostanie zaakceptowany.

Pojawia się pytanie:

Kto sprawdzi, czy konfiguracja jest zgodna z polityką bezpieczeństwa organizacji?

Odpowiedzią są Admission Controllers.

Czym są Admission Controllers?

Admission Controller to mechanizm działający wewnątrz API Server, który analizuje każdy obiekt zanim zostanie zapisany w bazie etcd.

Może:

• zaakceptować żądanie,
• zmodyfikować je,
• całkowicie je odrzucić.

Schemat:

kubectl apply

        |

        ↓

Authentication

        |

        ↓

Authorization (RBAC)

        |

        ↓

Admission Controllers

        |

        ↓

API Server

        |

        ↓

etcd

Admission Controller jest więc ostatnim etapem kontroli przed zapisaniem danych do klastra.

Tip eksperta

RBAC odpowiada na pytanie „kto może wykonać operację?”, natomiast Admission Controllers odpowiadają na pytanie „czy ta operacja spełnia nasze wymagania bezpieczeństwa?”. Oba mechanizmy uzupełniają się i powinny być stosowane równocześnie.

Kolejność przetwarzania żądania

Każde żądanie przechodzi przez kilka etapów.

User

↓

Authentication

↓

Authorization

↓

Mutating Admission

↓

Validating Admission

↓

etcd

Najpierw Kubernetes sprawdza tożsamość użytkownika.

Następnie:

• jego uprawnienia,
• modyfikacje obiektu,
• zgodność z politykami.

Dopiero wtedy dane trafiają do etcd.

Dwa rodzaje Admission Controllers

Istnieją dwa główne typy.

Mutating Admission Controllers

Mogą zmieniać obiekt.

Przykład:

Administrator tworzy:

imagePullPolicy: ""

Admission Controller automatycznie dodaje:

imagePullPolicy: IfNotPresent

lub:

securityContext:

  runAsNonRoot: true

Schemat:

Incoming Request

↓

Modify Object

↓

Continue

Validating Admission Controllers

Nie zmieniają konfiguracji.

Mogą jedynie:

• zaakceptować,
• odrzucić.

Przykład:

privileged: true

Rezultat:

Validation Failed

↓

Request Rejected

Dlaczego Admission Controllers są potrzebne?

Wyobraźmy sobie sytuację:

Developer wdraża:

hostNetwork: true

lub:

privileged: true

lub:

hostPID: true

RBAC pozwala na utworzenie Poda.

Admission Controller może powiedzieć:

Denied

i Pod nigdy nie zostanie uruchomiony.

Najważniejsze wbudowane Admission Controllers

Kubernetes posiada wiele kontrolerów.

Najczęściej spotykane:

• NamespaceLifecycle
• LimitRanger
• ResourceQuota
• DefaultStorageClass
• ServiceAccount
• PodSecurity
• ValidatingAdmissionPolicy
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

NamespaceLifecycle

Zapobiega tworzeniu zasobów w usuniętych Namespace.

Schemat:

Namespace Deleted

↓

New Pod

↓

Rejected

LimitRanger

Automatycznie ustawia limity zasobów.

Przykład:

Pod bez limitów:

resources: {}

Po modyfikacji:

resources:

  requests:

    cpu: 250m

    memory: 256Mi

  limits:

    cpu: 500m

    memory: 512Mi

Korzyści:

• brak niekontrolowanego zużycia CPU,
• brak wyczerpania pamięci.

ResourceQuota

Kontroluje wykorzystanie zasobów Namespace.

Przykład:

Namespace

↓

Maximum

20 Pods

10 CPU

32 GB RAM

Po przekroczeniu limitu:

Admission Denied

DefaultStorageClass

Jeżeli użytkownik nie poda StorageClass:

storageClassName: ""

Kubernetes może automatycznie przypisać domyślną klasę.

ServiceAccount

Automatycznie przypisuje ServiceAccount do nowych Podów.

Schemat:

Pod

↓

Default ServiceAccount

↓

API Access

Pod Security Admission

Od Kubernetes 1.25 zastąpił PodSecurityPolicy.

Pozwala wymusić poziomy bezpieczeństwa:

• Privileged
• Baseline
• Restricted

Przykład:

Namespace:

metadata:

  labels:

    pod-security.kubernetes.io/enforce: restricted

Efekt:

Privileged Pod

↓

Rejected

Tip eksperta

Dla większości środowisk produkcyjnych dobrym punktem wyjścia jest poziom Restricted, który wymusza uruchamianie kontenerów jako użytkownik nieuprzywilejowany, blokuje dostęp do hosta i ogranicza możliwości eskalacji uprawnień.

Admission Webhooks

Wiele organizacji tworzy własne polityki.

Schemat:

API Server

↓

Webhook

↓

Custom Validation

↓

Accept / Reject

Można sprawdzić:

• nazwy obrazów,
• podpisy obrazów,
• wymagane etykiety,
• polityki organizacji.

Mutating Webhook

Przykład:

Developer tworzy:

labels: {}

Webhook dodaje:

labels:

  owner: dev-team

  environment: production

Validating Webhook

Przykład:

Nie pozwalaj na użycie:

image: nginx:latest

Wymuszaj:

image: nginx:1.27.3

Rezultat:

latest

↓

Rejected

ValidatingAdmissionPolicy

Nowszy mechanizm Kubernetes umożliwiający definiowanie polityk bez konieczności tworzenia własnych webhooków.

Przykład:

Zakaz używania:

hostNetwork: true

lub:

privileged: true

Admission Controllers a bezpieczeństwo

Najczęściej blokowane są:

❌ privileged containers

❌ hostPath

❌ hostNetwork

❌ hostPID

❌ hostIPC

❌ latest tag

❌ brak limitów CPU

❌ brak limitów RAM

❌ brak SecurityContext

❌ brak ReadOnlyRootFilesystem

Przykład polityki bezpieczeństwa

Firma ustala:

Każdy Pod musi posiadać:

runAsNonRoot: true

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

Jeżeli czegoś brakuje:

Deployment

↓

Rejected

Integracja z OPA Gatekeeper

Bardzo popularnym rozwiązaniem jest:

Kubernetes

↓

OPA Gatekeeper

↓

Policies

↓

Admission

Przykładowe reguły:

• wymagane etykiety,
• ograniczenia Namespace,
• zakaz privileged,
• kontrola obrazów.

Integracja z Kyverno

Alternatywą jest:

Kyverno

Zalety:

• polityki zapisane w YAML,
• łatwa integracja,
• brak konieczności pisania Rego.

Przykład:

validate:

  message:

    "Containers must not run as root."

Tip eksperta

Jeżeli zespół nie zna języka Rego, Kyverno będzie zwykle prostsze we wdrożeniu. OPA Gatekeeper oferuje większą elastyczność, ale wymaga bardziej zaawansowanej wiedzy.

Audyt polityk

Sprawdzenie webhooków:

kubectl get validatingwebhookconfigurations

Mutating:

kubectl get mutatingwebhookconfigurations

Pod Security:

kubectl get ns --show-labels

Monitorowanie

Warto monitorować:

• liczbę odrzuconych żądań,
• czas działania webhooków,
• błędy walidacji,
• niedostępność webhooków.

Prometheus może zbierać metryki API Server związane z Admission Controllerami.

Najczęstsze błędy

❌ brak Admission Controllers

❌ używanie latest

❌ brak SecurityContext

❌ dopuszczanie privileged Podów

❌ brak walidacji obrazów

❌ zbyt wolne webhooki powodujące opóźnienia API

❌ tworzenie zbyt skomplikowanych polityk bez dokumentacji

Najlepsze praktyki

✅ stosuj Pod Security Admission

✅ używaj ValidatingAdmissionPolicy tam, gdzie to możliwe

✅ wymuszaj SecurityContext

✅ blokuj privileged: true

✅ wymagaj limitów CPU i RAM

✅ zabroń hostPath, jeśli nie jest konieczny

✅ kontroluj używane obrazy kontenerów

✅ testuj polityki przed wdrożeniem na produkcję

✅ monitoruj odrzucane żądania

Architektura procesu Admission

                 kubectl apply

                       |

                       ↓

                Authentication

                       |

                       ↓

                Authorization

                    (RBAC)

                       |

                       ↓

          Mutating Admission Controllers

                       |

                       ↓

         Validating Admission Controllers

                       |

                       ↓

                Kubernetes API Server

                       |

                       ↓

                     etcd

                       |

                       ↓

                 Kubernetes Cluster

Podsumowanie

Admission Controllers stanowią jeden z najważniejszych mechanizmów bezpieczeństwa Kubernetes. Umożliwiają wymuszanie standardów organizacyjnych i technicznych niezależnie od tego, kto wdraża aplikację.

Dzięki nim administrator może zablokować niebezpieczne konfiguracje jeszcze przed ich zapisaniem w klastrze, ograniczając ryzyko błędów oraz skutki potencjalnych ataków.

W nowoczesnych środowiskach produkcyjnych Admission Controllers powinny współpracować z:

• RBAC – kontrolą dostępu,
• Pod Security Admission – ochroną kontenerów,
• Network Policies – kontrolą komunikacji,
• Kyverno lub OPA Gatekeeper – zaawansowanym egzekwowaniem polityk,
• CI/CD – automatyczną weryfikacją konfiguracji przed wdrożeniem.

Najważniejsza zasada:

Najbezpieczniejszy Pod to taki, który nigdy nie został uruchomiony, ponieważ jego niebezpieczna konfiguracja została zatrzymana przez Admission Controller jeszcze przed zapisaniem w klastrze.

Polecane wpisy

Najlepszy przewodnik po konwersji dysków wirtualnych za pomocą VBoxManage i innych narzędzi

Najlepszy przewodnik po konwersji dysków wirtualnych za pomocą VBoxManage i innych narzędzi Konwersja dysków wirtualnych to częsty etap pracy administratorów Czytaj dalej

Czym są cyfrowe bliźniaki?

Nowoczesne technologie oraz nauka zaczynają coraz mocniej ingerować w świat przemysłu, wytwórczości oraz ściśle powiązanych z nimi logistyki i transportu. Czytaj dalej