Infrastructure tests i security tests: konfiguracja przed produkcją

Co to za rodzaj testu

Infrastructure test sprawdza kod i konfigurację środowiska.

Może dotyczyć:

Terraform
OpenTofu
Helm
Kubernetes manifests
Dockerfile
CI/CD pipeline
routing
NetworkPolicy
RBAC

Security test sprawdza ryzyko bezpieczeństwa.

W tej warstwie często oznacza:

sekrety
uprawnienia
obrazy kontenerów
zależności
ekspozycję sieci
TLS
policy
hardening

Te grupy nachodzą na siebie.

Policy test dla Kubernetes może być jednocześnie infrastructure testem i security testem.

Policy tests

Policy test sprawdza, czy konfiguracja spełnia reguły organizacji albo platformy.

Przykłady:

kontener nie działa jako root
Deployment ma readinessProbe
Service nie jest publiczny bez zgody
Pod ma limity zasobów
Ingress ma TLS
Terraform nie tworzy publicznego bucketa
RBAC nie daje wildcard permissions

To są decyzje, których zwykły test aplikacji nie zobaczy.

Aplikacja może działać.

Środowisko może być źle ustawione.

Deployment tests

Deployment test sprawdza sam proces wydania.

Nie tylko to, czy kod działa.

Przykłady:

artefakt ma właściwy tag
migracje uruchamiają się przed aplikacją
readinessProbe blokuje ruch do niegotowego Poda
rollback przywraca poprzednią wersję
canary dostaje tylko część ruchu
feature flag ma oczekiwany stan

Bez takich testów pipeline może wyglądać profesjonalnie i nadal promować złą wersję.

Security tests

Security test nie musi oznaczać pełnego pentestu.

W pipeline często zaczyna się od prostych, automatycznych kontroli:

SAST
dependency scanning
container image scanning
secret scanning
IaC scanning
DAST dla wybranych endpointów

To nie łapie wszystkiego.

Ale łapie klasę błędów, których nie powinien znajdować klient ani atakujący.

Security test jest szczególnie ważny tam, gdzie zmiana wygląda jak konfiguracja.

Publiczny bucket, zbyt szerokie RBAC albo brak NetworkPolicy nie muszą zmienić żadnego testu aplikacji.

Mogą za to zmienić powierzchnię ataku.

Synthetic tests

Synthetic test działa po wdrożeniu z perspektywy zewnętrznego obserwatora.

Może sprawdzać:

czy strona odpowiada
czy logowanie działa
czy certyfikat jest poprawny
czy endpoint z konkretnego regionu ma akceptowalny czas
czy checkout przechodzi przez minimalny scenariusz

Synthetic test nie zastępuje pipeline.

Jest dodatkową warstwą, która mówi, czy produkcyjny system naprawdę jest używalny.

Chaos tests

Chaos test kontrolowanie psuje część systemu.

Na przykład:

ubija Pod
odcina zależność
zwiększa latency
blokuje DNS
wypełnia dysk

Nie robi się tego po to, żeby udowodnić odwagę.

Robi się to, żeby sprawdzić założenia odporności:

czy retry działa
czy timeout jest ustawiony
czy fallback ma sens
czy alert przychodzi
czy runbook prowadzi do naprawy

Chaos test bez obserwowalności jest ryzykowny, bo można zepsuć system i nie nauczyć się niczego.

Narzędzie ze stacka

Do infrastructure tests wybrałbym Conftest z politykami OPA dla Terraform, OpenTofu i manifestów Kubernetes.

To dobrze pasuje do warstwy DevOps, bo testuje konfigurację przed wdrożeniem.

Przykładowe reguły:

brak publicznych bucketów
brak kontenerów jako root
wymagane readinessProbe
wymagane limity zasobów
zakaz wildcard RBAC

Do security scanów dołożyłbym Trivy dla obrazów i zależności.

W klastrze dobrą kontynuacją są policy w Kyverno, bo wtedy ta sama intencja działa już jako admission control.

Ostatnia bramka

Infrastructure tests i security tests zamykają serię, bo leżą najdalej od funkcji, ale bardzo blisko produkcji.

Na tej warstwie pytanie brzmi:

czy środowisko, do którego wysyłamy zmianę, nadal spełnia założenia aplikacji i organizacji?

Bez tej warstwy ostatnim testerem konfiguracji zostaje produkcja.

A produkcja jest bardzo droga jako narzędzie testowe.