Bezpieczeństwo obrazów kontenerów w środowiskach obronnych: hartowanie, skanowanie i integralność łańcucha dostaw

Obrazy kontenerów są atomową jednostką współczesnej dostawy oprogramowania obronnego. Każde obciążenie robocze działające na klastrach Kubernetes w środowiskach obronnych — aplikacje misji, potoki danych, usługi wnioskowania AI — dociera jako niezmienny obraz zbudowany gdzieś, z czegoś. Bezpieczeństwo wszystkich dalszych elementów zależy od integralności tego łańcucha budowania. W środowiskach korporacyjnych naruszony obraz kontenera to poważny incydent. W tajnym środowisku obronnym to potencjalny wektor zbierania danych wywiadowczych, mechanizm trwałego dostępu dla aktora państwowego lub punkt wejścia dla destrukcyjnych możliwości wymierzonych w infrastrukturę związaną z uzbrojeniem.

Niniejszy artykuł obejmuje pełny cykl życia bezpieczeństwa obrazów kontenerów w środowiskach obronnych: dobór i walidację obrazów bazowych zgodnych ze STIG, hartowanie kompilacji za pomocą wieloetapowych plików Dockerfile, uruchamianie skanowania podatności w izolowanych potokach CI/CD, podpisywanie obrazów za pomocą Cosign/Sigstore w środowiskach odłączonych od sieci, generowanie SBOM dla pakietów ATO oraz egzekwowanie kontroli integralności rejestru w Harbor. Artykuł jest skierowany do inżynierów platform i architektów bezpieczeństwa pracujących na tajnych lub wrażliwych systemach obronnych.

Dlaczego bezpieczeństwo obrazów kontenerów ma większe znaczenie w obronności niż w korporacjach

W korporacji podatny lub naruszony obraz kontenera oznacza ryzyko naruszenia danych, zakłócenia operacyjne i odpowiedzialność regulacyjną. W tajnym środowisku obronnym konsekwencje sięgają ujawnienia źródeł i metod, kompromitacji misji oraz efektów kinetycznych na systemy, które podatność oprogramowania może pozwolić przeciwnikowi kontrolować lub wyłączyć. Model zagrożeń jest jakościowo inny: przeciwnik to nie finansowo motywowana grupa przestępcza, lecz państwo prowadzące operacje trwałego dostępu z cierpliwością pozwalającą czekać latami na właściwy moment aktywacji zasadzonej zdolności.

Ataki na łańcuch dostaw kontenerów wykorzystują warstwową naturę obrazów kontenerów. Typowy obraz aplikacji misji może być zbudowany FROM bazowego obrazu systemu operacyjnego, który instaluje pakiety środowiska uruchomieniowego z repozytorium pakietów, które z kolei zawierają zależności przechodnie pobierane w czasie kompilacji z rejestrów pakietów języków programowania. Przeciwnik nie musi kompromitować wewnętrznych systemów wykonawcy obronnego — skompromitowanie zależności trzy poziomy głębiej w tym łańcuchu osiąga ten sam efekt. Incydenty SolarWinds i XZ Utils wykazały, że ten model zagrożeń nie jest teoretyczny; oba były wstawieniami do łańcucha dostaw, które byłyby technicznie niewykrywalne bez głębokich kontroli łańcucha dostaw.

Środowiska obronne dodają trzy wymagania, które czynią bezpieczeństwo obrazów kontenerów znacznie bardziej złożonym operacyjnie niż w środowiskach korporacyjnych:

• Wymagania izolacji sieciowej (air-gap). Sieci tajne nie mogą pobierać obrazów z rejestrów internetowych w czasie wykonywania. Każda zależność obrazu musi zostać wcześniej zatwierdzona, przeskanowana i odzwierciedlona w rejestrze wewnętrznym — co oznacza, że granica łańcucha dostaw jest twardym obwodem, który zespoły inżynierskie w pełni posiadają i są odpowiedzialne za jego pilnowanie.
• Wymagania formalnej autoryzacji. Oprogramowanie działające na systemach tajnych musi ukończyć proces Authorization to Operate (ATO), który wymaga udokumentowanego rodowodu dla każdego komponentu oprogramowania. Generowanie SBOM i podpisywanie obrazów przechodzi z opcjonalnych praktyk higienicznych do obowiązkowych dowodów ATO.
• Egzekwowanie niezmiennej infrastruktury. Platformy obronne coraz częściej wymagają, aby żadna modyfikacja obrazów kontenerów w czasie wykonywania nie była dozwolona: kontenery są niszczone i zastępowane, nigdy nie łatane w miejscu. Oznacza to, że stan bezpieczeństwa wdrożonego obciążenia roboczego jest trwale ustalony w czasie budowania obrazu, co czyni hartowanie i bramki skanowania w czasie kompilacji koniecznymi, a nie tylko dobrymi praktykami.

Obrazy bazowe zgodne ze STIG

DISA (Defense Information Systems Agency) publikuje Security Technical Implementation Guides (STIG) dla systemów operacyjnych i platform używanych w środowiskach obronnych. Dla obciążeń skonteneryzowanych najbardziej operacyjnie istotne są STIG RHEL 8 i STIG RHEL 9, które dotyczą pochodnych Red Hat Universal Base Image (UBI) — najczęściej używanych obrazów bazowych na platformach kontenerowych obronności, w tym repozytorium zahartowanych obrazów Iron Bank platformy DoD Platform One.

STIG RHEL egzekwuje kontrole w kilku kategoriach, które różnią się zasadniczo od domyślnej instalacji systemu operacyjnego:

• Parametry jądra (sysctl). Przekazywanie IP domyślnie wyłączone (net.ipv4.ip_forward=0), przekierowania ICMP odrzucane, pliki cookie TCP SYN włączone i wymuszona randomizacja przestrzeni adresowej wirtualnej (ASLR). Kontrole te zmniejszają ekspozycję systemu operacyjnego jako przekaźnika sieciowego i utrudniają exploitację pamięci.
• Konfiguracja PAM. Reguły złożoności haseł (minimalna długość, klasy znaków), blokada konta po nieudanych próbach uwierzytelnienia i wymagania rejestrowania sesji. W przypadku kont serwisowych kontenerów używających uwierzytelniania opartego na kluczach lub tokenach niektóre z tych kontroli mogą wymagać udokumentowanych wyjątków.
• Reguły auditd. STIG określa kompleksowy zestaw reguł auditd obejmujących dostęp do systemu plików na wrażliwych ścieżkach, użycie poleceń eskalacji uprawnień (sudo, su), modyfikacje baz użytkowników i grup, zmiany konfiguracji sieci oraz ładowanie modułów jądra. W kontekście kontenerowym auditd zazwyczaj działa na jądrze hosta i dotyczy wszystkich kontenerów — reguły STIG należy stosować na poziomie węzła, nie per-kontener.
• Polityka kryptograficzna FIPS 140. STIG wymaga, aby ogólnosystemowa polityka kryptograficzna była ustawiona na FIPS lub FIPS:OSCP, co wyłącza TLS 1.0/1.1, MD5, SHA-1 dla podpisów, RC4 i DES/3DES. Komponenty aplikacji zależne od przestarzałych algorytmów zawiodą pod polityką kryptograficzną FIPS — jest to częsty problem integracyjny odkrywany późno w projektach hartowania, gdy obraz bazowy STIG jest walidowany względem zestawów testów aplikacji.

Iron Bank (zahartowane repozytorium kontenerów Platform One) publikuje wstępnie zahartowane obrazy, które zostały zwalidowane względem STIG DISA, przeskanowane pod kątem podatności i podpisane. Dla programów już na Platform One budowanie FROM obrazu bazowego Iron Bank jest najbardziej praktycznym podejściem: zapewnia udokumentowany, wstępnie autoryzowany punkt odniesienia spełniający wymagania obrazu bazowego większości ATO. Dla programów nie będących na Platform One, budowanie i walidacja zgodności STIG niezależnie za pomocą OpenSCAP (oscap-docker lub oscap względem wyeksportowanego systemu plików kontenera) jest równoważnym procesem.

# Walidacja systemu plików obrazu kontenera względem STIG RHEL 9
# Eksport systemu plików obrazu do tymczasowego katalogu
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# Uruchomienie OpenSCAP względem wyeksportowanego systemu plików
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results /tmp/stig-results.xml \
  --report /tmp/stig-report.html \
  --chroot /tmp/image-fs \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Hartowanie kompilacji wieloetapowych

Wieloetapowe kompilacje Docker są najskuteczniejszą pojedynczą techniką zmniejszania powierzchni ataku obrazu kontenera. Zasada jest prosta: użyj jednego lub więcej pośrednich etapów kompilacji zawierających wszystkie narzędzia wymagane do kompilacji i pakowania aplikacji, a do końcowego etapu środowiska uruchomieniowego skopiuj tylko skompilowane artefakty — nic, czego aplikacja nie potrzebuje do działania. Aplikacja C++ zbudowana w etapie zawierającym gcc, make, cmake i nagłówki deweloperskie tworzy końcowy obraz zawierający jedynie plik binarny i jego biblioteki współdzielone środowiska uruchomieniowego.

# Etap 1: kompilacja — pełny łańcuch narzędzi, nieobecny w obrazie końcowym
FROM registry.mil/ironbank/redhat/ubi/ubi9:latest AS builder
RUN dnf install -y gcc make cmake openssl-devel && dnf clean all
WORKDIR /build
COPY src/ .
RUN cmake -DCMAKE_BUILD_TYPE=Release . && make -j$(nproc)

# Etap 2: środowisko uruchomieniowe — minimalna baza, brak narzędzi kompilacji
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Użytkownik niebędący rootem — wymaganie hartowania STIG i NSA
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

W przypadku statycznie kompilowanych aplikacji Go lub Rust końcowy etap może być scratch — całkowicie pustym obrazem zawierającym tylko plik binarny. Eliminuje to warstwę systemu operacyjnego w całości, usuwając wszystkie podatności na poziomie systemu operacyjnego z powierzchni wykrycia skanera. Możliwości kompilacji krzyżowej i statycznego linkowania standardowej biblioteki Go sprawiają, że obrazy scratch są praktyczne dla szerokiej klasy mikroserwisów obronnych bez dodatkowej złożoności kompilacji.

Gdy aplikacja wymaga powłoki lub narzędzi systemu operacyjnego w czasie wykonywania (debugowanie w trakcie tworzenia, skrypty sprawdzania zdrowia, logika inicjalizacji), obrazy gcr.io/distroless zapewniają złoty środek: minimalną bazę Debian lub Alpine zawierającą tylko środowisko uruchomieniowe języka i bibliotekę C, bez powłoki, bez menedżera pakietów i bez narzędzi systemowych. Obrazy distroless są utrzymywane przez Google i publikowane z wynikami skanowania podatności; programy obronne używające distroless powinny odzwierciedlać te obrazy do swojego wewnętrznego rejestru i utrzymywać własne rejestry oceny podatności.

Egzekwowanie użytkownika niebędącego rootem jest wymaganiem hartowania zarówno w Przewodniku hartowania Kubernetes NSA, jak i w STIG. Instrukcja USER w pliku Dockerfile ustawia domyślnego użytkownika dla wszystkich kolejnych poleceń i punktu wejścia kontenera. Użyj numerycznego UID (nie nazwanego użytkownika), aby uniknąć zależności od pliku /etc/passwd, i wybierz UID powyżej 10000, aby uniknąć konfliktów z zakresami użytkowników systemowych. Kontrolery dopuszczenia egzekwujące profil restricted Pod Security odrzucą pody, w których runAsNonRoot nie jest prawdziwe lub gdzie kontener deklaruje runAsUser: 0.

Skanowanie podatności w tajnych potokach CI/CD

Skanowanie podatności jest bramką jakości zapobiegającą przedostaniu się obrazów z podatnymi CVE do tajnych wdrożeń. Dwa skanery open source dominują w implementacjach platform kontenerowych obronności: Trivy (Aqua Security) i Grype (Anchore). Oba obsługują działanie offline — wymaganie niepodlegające negocjacjom dla potoków CI/CD w izolowanych środowiskach obronnych.

Tryb offline Trivy wymaga wcześniejszego pobrania bazy danych podatności i przeniesienia jej do środowiska izolowanego sieciowo. Baza danych obejmuje pakiety systemów operacyjnych (RPM, DEB, APK), pakiety ekosystemów językowych (pip, npm, Maven, moduły Go, Cargo) oraz sygnatury binarne aplikacji. Przepływ pracy transferu z użyciem nośników wymiennych lub rozwiązania cross-domain musi być zintegrowany z regularnymi operacjami zespołu jako zaplanowane zadanie — przestarzała baza danych (starsza niż 14 dni) to częste odkrycie w ocenach bezpieczeństwa tajnych środowisk.

# Na systemie połączonym z internetem — pobieranie bazy danych Trivy
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# Przeniesienie /transfer/trivy-cache do systemu izolowanego przez zatwierdzone nośniki

# Na izolowanym węźle CI/CD — skanowanie obrazu z lokalną bazą danych
trivy image \
  --skip-update \
  --cache-dir /opt/trivy-cache \
  --severity CRITICAL,HIGH \
  --exit-code 1 \
  --ignore-unfixed \
  --format json \
  --output /artifacts/scan-results.json \
  registry.classified.mil/myapp@sha256:abc123...

# Odpowiednik Grype — wyłącz automatyczne aktualizacje, wskaż lokalną bazę danych
GRYPE_DB_AUTO_UPDATE=false \
GRYPE_DB_CACHE_DIR=/opt/grype-db \
grype registry.classified.mil/myapp@sha256:abc123... \
  --fail-on critical \
  --output json > /artifacts/grype-results.json

Bramki polityki skanowania definiują, które wyniki blokują kompilację potoku, a które generują ostrzeżenia. Defensywna polityka bramek dla tajnych środowisk:

• Blokuj (potok się nie powiedzie, obraz nie zostanie wypchnięty): każde CVE o ważności CRITICAL, każde CVE o ważności HIGH w bezpośredniej zależności z pod-wynikiem exploitability CVSS powyżej 7,0 lub wynikiem EPSS powyżej 0,05.
• Ostrzeż i wymagaj zezwolenia: CVE o ważności HIGH w zależnościach przechodnich, CVE o ważności HIGH, dla których nie jest dostępna łatka dostawcy, CVE o ważności MEDIUM.
• Tylko informacyjnie: wyniki LOW i NEGLIGIBLE, CVE dotyczące komponentów, które są wyraźnie nieosiągalne w ścieżce wykonywania aplikacji.

Każde zezwolenie musi być podpisanym, ograniczonym czasowo dokumentem łączącym identyfikator CVE, uzasadnienie (brak dostępnej łatki, komponent nieosiągalny, kontrola kompensująca), zatwierdzającego oficera bezpieczeństwa i datę wygaśnięcia wywołującą ponowną ocenę. Zezwolenia przechowywane jako pliki YAML przeglądane przez kod w repozytorium CI/CD zapewniają audytowalny zapis spełniający wymagania dowodów ATO.

Podpisywanie obrazów z Cosign/Sigstore w środowiskach odłączonych

Podpisywanie obrazów zapewnia kryptograficzny dowód, że konkretny obraz kontenera — identyfikowany przez skrót SHA-256 jego treści — został wyprodukowany przez autoryzowany potok i nie był modyfikowany od czasu podpisania. Cosign (część projektu Sigstore Linux Foundation) stał się standardowym narzędziem do podpisywania obrazów w środowiskach kontenerowych, produkującym podpisy zgodne z OCI przechowywane jako artefakty w tym samym rejestrze co obraz.

Przepływ podpisywania bez kluczy Sigstore używa tokenów tożsamości OIDC i publicznej infrastruktury (CA Fulcio i dziennik przejrzystości Rekor) do podpisywania obrazów bez zarządzania długotrwałymi kluczami prywatnymi. Ten model dobrze nadaje się do publicznego open-source CI/CD, ale wymaga dostępu do internetu do publicznej infrastruktury Sigstore — co jest niezgodne z tajnymi środowiskami izolowanymi sieciowo. Odłączone środowiska mają dwie praktyczne opcje:

• Podpisywanie z kluczem (zalecane dla środowisk tajnych). Wygeneruj parę kluczy Cosign; przechowuj klucz prywatny w HSM lub zatwierdzonym menedżerze sekretów (HashiCorp Vault z backEndem zwalidowanym FIPS, AWS CloudHSM lub Azure Dedicated HSM). Etap podpisywania w potoku CI/CD pobiera odniesienie do klucza i podpisuje skrót obrazu. Klucz publiczny jest dystrybuowany do kontrolerów dopuszczenia w celu weryfikacji. Nie jest wymagana żadna zewnętrzna infrastruktura.
• Prywatna instancja Sigstore. Wdróż Fulcio i Rekor wewnątrz sieci tajnej. Zapewnia to UX bez kluczy i korzyści dziennika przejrzystości, ale wymaga obsługi dodatkowej infrastruktury, w tym wewnętrznego dostawcy tożsamości OIDC. Odpowiednie dla dużych programów z dedykowanymi zespołami inżynierów platform.

# Generowanie pary kluczy Cosign (raz, klucz prywatny w HSM/Vault)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Podpisanie obrazu po pomyślnym przejściu bramek skanowania — odwołanie do obrazu przez skrót, nie tag
IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myapp:v1.2.3)
cosign sign \
  --key awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def \
  --tlog-upload=false \
  registry.classified.mil/myapp@${IMAGE_DIGEST}

# Weryfikacja podpisu (używana przez kontrolery dopuszczenia i podczas ręcznych audytów)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

Egzekwowanie weryfikacji podpisów obrazów przez kontroler dopuszczenia zamyka lukę między podpisywaniem w potoku a wdrożeniem w czasie wykonywania. ClusterPolicy Kyverno z regułą verifyImages odmawia każdemu podowi, który odwołuje się do obrazu bez ważnego podpisu z zatwierdzonego klucza publicznego Cosign. Polityka powinna również włączyć mutateDigest: true, który przepisuje mutowalne odwołania do tagów na niezmienne odwołania do skrótów w specyfikacji poda w czasie dopuszczenia — zapewniając, że środowisko uruchomieniowe kontenera pobiera dokładnie obraz, który został zweryfikowany, a nie kolejne wypchnięcie na ten sam tag.

Generowanie SBOM dla pakietów ATO

Software Bill of Materials (SBOM) to czytelny maszynowo inwentarz każdego komponentu oprogramowania w wdrożonym artefakcie — pakiety systemu operacyjnego, biblioteki środowiska uruchomieniowego języka, zależności aplikacji i ich relacje. Dla pakietów ATO SBOM zapewnia oficerowi autoryzującemu wgląd w łańcuch dostaw oprogramowania wdrożonego systemu i jest coraz częściej wymaganym wynikiem zgodnie z polityką zamówień oprogramowania DoD i wytycznymi CISA wdrażającymi Executive Order 14028.

Syft (Anchore) jest standardowym generatorem SBOM open source dla obrazów kontenerów. Skanuje system plików obrazu warstwa po warstwie, identyfikuje pakiety zarówno na podstawie rekordów bazy danych pakietów systemu operacyjnego, jak i plików lock ekosystemów językowych, i wyprowadza ustrukturyzowane dokumenty SBOM. Uruchomienie Syft względem końcowego skrótu obrazu (nie pliku Dockerfile ani repozytorium źródłowego) przechwytuje rzeczywisty wdrożony zestaw komponentów, w tym pakiety zainstalowane przechodnio lub dodane podczas procesu kompilacji, które nie są wyraźnie wymienione w plikach zależności aplikacji.

# Generowanie SBOM w formatach SPDX i CycloneDX z końcowego obrazu
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# Dołączenie SBOM do obrazu w rejestrze (przechowywany jako artefakt OCI)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# Weryfikacja dołączenia SBOM
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

W kwestii wyboru między SPDX a CycloneDX: oba formaty są akceptowane przez wytyczne CISA i zdolne do reprezentowania tych samych informacji o komponentach. SPDX (ISO/IEC 5962:2021) jest starszym standardem z silniejszym mandatem w kontekstach rządowych; CycloneDX ma silniejsze wsparcie narzędziowe dla wzbogacania podatności za pomocą dokumentów VEX (Vulnerability Exploitability eXchange). Dla egzekwowania SBOM w potokach obronnych, generowanie obu formatów z jednego wywołania Syft nic nie kosztuje i zapewnia zgodność z każdym downstream narzędziem ATO lub preferencją oficera autoryzującego.

SBOM przekazane oficerowi autoryzującemu powinno być uzupełnione dokumentem ujawnienia podatności odwzorowującym identyfikatory komponentów SBOM na wyniki skanowania i ich dyspozycję (załatane, zwolnione z uzasadnieniem, nieafektowane). Ten połączony pakiet — skrót obrazu, SBOM, wyniki skanowania, zezwolenia i podpis Cosign — tworzy zestaw dowodów łańcucha dostaw, którego audytorzy używają do oceny wiarygodności wdrożonego systemu.

Bezpieczeństwo rejestru obrazów kontenerów

Harbor to rejestr kontenerów z certyfikatem CNCF, najszerzej wdrażany w środowiskach obronnych i tajnych. Jego zestaw funkcji odpowiada konkretnym wymaganiom operacyjnym rejestrów obronnych: niezmienność tagów, integracja zaufania treści z Cosign, kontrola dostępu oparta na rolach, integracja skanowania podatności (Trivy) i polityki replikacji dla sieci rejestrów wieloobwodowych. Uruchomienie Harbor w tajnym środowisku wymaga uwagi na kilka obszarów konfiguracji, których domyślne ustawienia nie egzekwują.

Niezmienność tagów zapobiega nadpisaniu istniejącego tagu obrazu przez jakąkolwiek operację wypchnięcia. Bez tej kontroli skompromitowane konto serwisowe CI/CD lub źle skonfigurowany potok mógłby po cichu zastąpić zatwierdzony, podpisany obraz złośliwym lub niepodpisanym pod tym samym tagiem. Reguły niezmienności tagów Harbor są konfigurowane per projekt i mogą być ograniczone do określonych wzorców tagów — na przykład blokowanie wszystkich tagów pasujących do v[0-9]* (wersje wydań) przy jednoczesnym dopuszczeniu mutowalnych tagów dev-* w projektach deweloperskich.

Polityka zaufania treści w Harbor integruje się z Cosign, aby egzekwować weryfikację podpisów w czasie pobierania. Gdy zaufanie treści jest włączone dla projektu, warstwa proxy Harbor wywołuje cosign verify dla każdego żądania pobierania obrazu i zwraca błąd autoryzacji, jeśli obraz nie ma ważnego podpisu z skonfigurowanego klucza publicznego. Zapewnia to egzekwowanie na poziomie rejestru niezależnie od kontrolera dopuszczenia Kubernetes — obrazy nie mogą być pobierane nawet przez narzędzia omijające webhook dopuszczenia.

# Konfiguracja projektu Harbor przez CLI (harbor-cli lub curl względem API Harbor)
# Włączenie niezmienności tagów dla projektu produkcyjnego
curl -X POST https://registry.classified.mil/api/v2.0/projects/mission-apps/immutabletagrules \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{
    "action": "immutableTagRule",
    "scope_selectors": {"repository": [{"decoration": "repoMatches","pattern": "**"}]},
    "tag_selectors": [{"decoration": "matches","pattern": "v[0-9]*"}]
  }'

# Włączenie skanowania podatności przy wypchnięciu dla wszystkich projektów
curl -X PUT https://registry.classified.mil/api/v2.0/projects/mission-apps \
  -H "Content-Type: application/json" \
  -u "admin:${HARBOR_ADMIN_PASSWORD}" \
  -d '{"metadata": {"auto_scan": "true", "severity": "critical"}}'

Pamięć podręczna pull-through w Harbor pełni kluczową funkcję w architekturach wieloobwodowych. Połączona (o niższym poziomie klasyfikacji) instancja Harbor jest skonfigurowana z projektami proxy cache wskazującymi na zatwierdzone zewnętrzne rejestry (Red Hat Registry, Iron Bank). Po stronie tajnej oddzielna instancja Harbor nie ma skonfigurowanego rejestru nadrzędnego — obsługuje tylko obrazy, które zostały pobrane przez pamięć podręczną po stronie połączonej, przeskanowane, podpisane i fizycznie przeniesione do rejestru po stronie tajnej za pomocą zatwierdzonego mechanizmu transferu cross-domain. Tworzy to kontrolowany przepływ promowania obrazów, w którym każdy obraz musi przejść kontrole bezpieczeństwa przed wejściem do tajnego środowiska, a nie przy wejściu.

Polityka zbierania śmieci w Harbor usuwa nieoznaczone manifesty i nieużywane warstwy według zdefiniowanego harmonogramu. W tajnych środowiskach o ograniczonej pojemności pamięci masowej zbieranie śmieci zapobiega nieograniczonemu wzrostowi pamięci rejestru wraz z zastępowaniem obrazów nowymi wersjami. Zalecana konfiguracja uruchamia zbieranie śmieci co tydzień podczas okna konserwacyjnego, zachowuje konfigurowalną liczbę historycznych otagowanych obrazów na repozytorium dla możliwości wycofania i generuje dziennik usunięć dla audytowalności. Usuwanie obrazów w tajnym rejestrze musi być skoordynowane z wymaganiami dotyczącymi przechowywania dowodów ATO — artefakty SBOM i skanowania dla wdrożonych wersji obrazów mogą wymagać przechowywania poza cyklem życia obrazu.