Bezpieczeństwo obrazów kontenerów od builda do runtime

Bezpieczeństwo obrazów kontenerów zaczyna się przed docker build i kończy dopiero po wycofaniu wdrożenia. Skan CVE jest ważny, ale nie wykryje skradzionego sekretu, złośliwego etapu CI, obrazu podmienionego w registry ani nadmiernych uprawnień w runtime.

NIST SP 800-190 zaleca traktowanie obrazów, rejestrów, orkiestratora, hosta i samych kontenerów jako powiązanych warstw ryzyka.

Minimalny i powtarzalny build

Używaj małych, utrzymywanych obrazów bazowych i przypinaj je do niezmiennego digestu. Tag latest nie gwarantuje, że test i produkcja uruchomią te same bajty. Multi-stage build ogranicza narzędzia kompilacyjne w finalnym obrazie.

Usuń menedżery pakietów, powłoki i narzędzia diagnostyczne, jeśli aplikacja ich nie potrzebuje. Nie kopiuj całego repozytorium. .dockerignore powinien wykluczać .git, lokalne konfiguracje, klucze i artefakty testowe.

Sekrety nie mogą trafić do warstw

Usunięcie pliku w późniejszej instrukcji nie usuwa go z wcześniejszej warstwy. Sekrety dostarczaj mechanizmem build secrets, a w runtime przez menedżer sekretów i pliki tymczasowe lub workload identity.

Skanuj wynikowy obraz pod kątem tokenów, kluczy prywatnych i danych uwierzytelniających. Po wykryciu sekretu rotuj go — samo przebudowanie obrazu nie unieważnia wycieku.

SBOM, CVE i kontekst

Generuj SBOM dla każdego wydania i przechowuj go z attestation. Skanuj system operacyjny oraz zależności aplikacji. Priorytetyzuj podatności według dostępności poprawki, wykorzystania pakietu, ekspozycji oraz dowodów aktywnego wykorzystania, nie tylko CVSS.

Obraz zaakceptowany dziś może stać się podatny jutro po publikacji nowego CVE. Skanuj ponownie registry i uruchomione workloady, a poprawki wdrażaj przez nowy, niezmienny obraz.

Podpis i polityka dopuszczenia

Podpisuj obrazy oraz attestation z zaufanego CI. Admission policy powinna dopuszczać wyłącznie artefakty z zatwierdzonego registry, właściwego workflow i akceptowalnym poziomem ryzyka.

Weryfikacja podpisu bez ochrony pipeline’u dowodzi jedynie, że skompromitowany proces poprawnie podpisał złośliwy artefakt. Połącz ją z bezpieczeństwem łańcucha dostaw.

Runtime nadal ma znaczenie

Uruchamiaj proces jako użytkownik nie-root, z systemem plików tylko do odczytu, bez privileged, zbędnych capabilities i montowania socketu Dockera. Ogranicz sieć oraz używaj profili seccomp, AppArmor lub SELinux.

Digest obrazu powinien odpowiadać zatwierdzonemu artefaktowi. Monitoruj nieoczekiwane procesy, zapis do ścieżek systemowych i połączenia wychodzące. Instrukcje hardeningu uzupełnia bezpieczeństwo Kubernetes.

Checklista pipeline’u

1. Przypnij zaufany obraz bazowy do digestu.
2. Zbuduj minimalny finalny stage bez sekretów.
3. Wygeneruj SBOM i przeskanuj zależności.
4. Podpisz obraz i provenance w CI.
5. Wymuś politykę admission przed wdrożeniem.
6. Uruchom bez roota i zbędnych uprawnień.
7. Skanuj registry po publikacji nowych CVE.
8. Wycofuj nieużywane oraz niewspierane obrazy.

Bezpieczny obraz jest wynikiem kontrolowanego procesu. Pojedynczy zielony skan nie zastępuje pochodzenia, polityki wdrożenia i ochrony runtime.

---

Bramka między rejestrem a klastrem

Skan wykonany przy pull requeście szybko się starzeje, bo nowe CVE pojawiają się po zbudowaniu obrazu. Skanuj ponownie rejestr, przypisuj obrazy do właścicieli i ustal SLA zależne od ekspozycji. Polityka admission powinna dopuszczać wyłącznie obrazy z zatwierdzonego rejestru, podpisem lub zweryfikowaną atestacją oraz niezmiennym digestem.

Minimalny obraz ogranicza powierzchnię, ale nie usuwa podatności aplikacji. W runtime połącz nieuprzywilejowanego użytkownika, system plików tylko do odczytu, ograniczone capabilities, limity zasobów i profile seccomp. Wyjątki muszą wskazywać workload, powód i termin. Retest obejmuje możliwość uruchomienia powłoki, zapis do wrażliwych ścieżek i dostęp do metadanych chmury.

Źródła: NIST SP 800-190, SLSA Specification, Kubernetes — Images.