Securitatea imaginilor de container pentru apărare: întărire, scanare și integritatea lanțului de aprovizionare

Imaginile de container reprezintă unitatea atomică a livrării moderne de software pentru apărare. Fiecare sarcină de lucru care rulează pe clustere Kubernetes pentru apărare — aplicații de misiune, pipeline-uri de date, servicii de inferență AI — ajunge ca o imagine imutabilă care a fost construită undeva, din ceva. Securitatea tuturor elementelor din aval depinde de integritatea acelui lanț de construcție. În mediile enterprise, o imagine de container compromisă reprezintă un incident grav. Într-un mediu de apărare clasificat, ea constituie un potențial vector de colectare a informațiilor, un mecanism de persistență pentru un actor statal sau punctul de intrare pentru capacități distructive care vizează infrastructuri legate de sisteme de armament.

Acest articol acoperă ciclul complet de securitate al imaginilor de container pentru apărare: selectarea și validarea imaginilor de bază conforme STIG, întărirea construcțiilor cu Dockerfile-uri multi-etapă, rularea scanării vulnerabilităților în pipeline-uri CI/CD izolate de internet, semnarea imaginilor cu Cosign/Sigstore în medii deconectate, generarea SBOM pentru pachete ATO și aplicarea controalelor de integritate a registrului în Harbor. Publicul țintă îl constituie inginerii de platformă și arhitecții de securitate care lucrează la sisteme de apărare clasificate sau sensibile.

De ce securitatea imaginilor de container contează mai mult în apărare decât în mediul enterprise

Într-un mediu enterprise comercial, o imagine de container vulnerabilă sau compromisă reprezintă un risc de breșă de date, întrerupere operațională și răspundere reglementară. Într-un mediu de apărare clasificat, consecințele se extind la expunerea surselor și metodelor, compromiterea misiunii și efecte cinetice asupra sistemelor pe care o vulnerabilitate software le poate permite unui adversar să le controleze sau dezactiveze. Modelul de amenințare este calitativ diferit: adversarul nu este un grup criminal motivat financiar, ci un actor statal cu operațiuni de acces persistent și răbdarea de a aștepta ani pentru momentul potrivit de a activa o capacitate plantată.

Atacurile asupra lanțului de aprovizionare al containerelor exploatează natura stratificată a imaginilor de container. O imagine tipică de aplicație de misiune poate fi construită FROM o imagine de bază a sistemului de operare, care instalează pachete de rulare dintr-un depozit de pachete, care la rândul lor includ dependențe tranzitive trase la momentul construcției din registrele de pachete ale ecosistemului de limbaj din amonte. Adversarul nu trebuie să compromită sistemele interne ale contractorului de apărare — compromiterea unei dependențe la trei niveluri adâncime în acel lanț produce același efect. Incidentele SolarWinds și XZ Utils au demonstrat că acest model de amenințare nu este teoretic; ambele au fost inserții în lanțul de aprovizionare care ar fi fost tehnic nedetectabile fără controale profunde ale lanțului de aprovizionare.

Mediile de apărare adaugă trei cerințe care fac securitatea imaginilor de container semnificativ mai complexă din punct de vedere operațional decât în mediile enterprise:

• Cerințe de izolare de internet. Rețelele clasificate nu pot extrage imagini din registrele de pe internet la momentul rulării. Fiecare dependență de imagine trebuie pre-aprobată, pre-scanată și oglindită într-un registru intern înainte de a putea fi utilizată — ceea ce înseamnă că granița lanțului de aprovizionare este un perimetru strict pe care echipele de inginerie îl dețin și sunt responsabile să îl monitorizeze.
• Cerințe de autorizare formală. Software-ul care rulează pe sisteme clasificate trebuie să finalizeze un proces de Autorizare de Operare (ATO), care necesită documentarea provenienței fiecărei componente software. Generarea SBOM și semnarea imaginilor trec de la practici opționale de igienă la livrabile obligatorii de dovezi ATO.
• Aplicarea infrastructurii imutabile. Platformele de apărare impun din ce în ce mai mult că nicio modificare la rulare a imaginilor de container nu este permisă: containerele sunt distruse și înlocuite, niciodată remediate în loc. Aceasta înseamnă că postura de securitate a unei sarcini de lucru implementate este stabilită permanent la momentul construcției imaginii, ceea ce face ca întărirea și porțile de scanare la momentul construcției să fie non-negociabile, nu doar un efort de bune practici.

Imagini de bază conforme STIG

DISA (Defense Information Systems Agency) publică Ghiduri de Implementare Tehnică de Securitate (STIG) pentru sistemele de operare și platformele utilizate în mediile de apărare. Pentru sarcinile de lucru containerizate, cele mai relevante din punct de vedere operațional sunt RHEL 8 STIG și RHEL 9 STIG, care se aplică derivatelor Red Hat Universal Base Image (UBI) — cele mai frecvent utilizate imagini de bază în platformele de containere pentru apărare, inclusiv depozitul de imagini întărite Iron Bank al DoD Platform One.

RHEL STIG aplică controale în mai multe categorii care diferă semnificativ față de o instalare implicită a sistemului de operare:

• Parametri kernel (sysctl). Redirecționarea IP dezactivată implicit (net.ipv4.ip_forward=0), redirecționările ICMP respinse, cookie-urile TCP SYN activate și spațiul de adrese virtuale randomizat (ASLR) aplicat. Aceste controale reduc expunerea sistemului de operare ca releu de rețea și îngreunează exploatarea memoriei.
• Configurare PAM. Reguli de complexitate a parolei (lungime minimă, clase de caractere), blocare cont după tentative de autentificare eșuate și cerințe de înregistrare a sesiunii. Pentru conturile de serviciu ale containerelor care utilizează autentificare bazată pe chei sau token, unele dintre aceste controale pot necesita excepții documentate.
• Reguli auditd. STIG specifică un set cuprinzător de reguli auditd care acoperă accesul la sistemul de fișiere pentru căi sensibile, utilizarea comenzilor de escaladare a privilegiilor (sudo, su), modificarea bazelor de date de utilizatori și grupuri, modificările configurației de rețea și încărcarea modulelor kernel. Într-un context de container, auditd rulează de obicei pe kernel-ul gazdă și se aplică tuturor containerelor — regulile STIG trebuie aplicate la nivelul nodului, nu per-container.
• Politică criptografică FIPS 140. STIG cere ca politica criptografică la nivel de sistem să fie setată la FIPS sau FIPS:OSCP, care dezactivează TLS 1.0/1.1, MD5, SHA-1 pentru semnături, RC4 și DES/3DES. Componentele aplicației care depind de algoritmi deprecați vor eșua sub politica cripto FIPS — aceasta este o problemă de integrare frecventă descoperită târziu în proiectele de întărire, când imaginea de bază STIG este validată față de suitele de teste ale aplicației.

Iron Bank (registrul de containere întărite al Platform One) publică imagini pre-întărite care au fost validate față de DISA STIG-uri, scanate pentru vulnerabilități și semnate. Pentru programele care se află deja pe Platform One, construirea FROM o imagine de bază Iron Bank este abordarea cea mai practică: oferă o bază documentată și pre-autorizată care satisface cerințele de imagine de bază ale majorității ATO-urilor. Pentru programele care nu se află pe Platform One, construirea și validarea conformității STIG în mod independent folosind OpenSCAP (oscap-docker sau oscap față de un sistem de fișiere al containerului exportat) reprezintă procesul echivalent.

# Validați un sistem de fișiere al imaginii de container față de RHEL 9 STIG
# Exportați sistemul de fișiere al imaginii într-un director temporar
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# Rulați OpenSCAP față de sistemul de fișiere exportat
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

Întărirea construcției multi-etapă

Construcțiile Docker multi-etapă reprezintă cea mai eficientă tehnică individuală pentru reducerea suprafeței de atac a imaginilor de container. Principiul este simplu: utilizați una sau mai multe etape intermediare de construcție care conțin toate instrumentele necesare pentru compilarea și împachetarea aplicației și copiați doar artefactele compilate într-o etapă finală de rulare care nu conține nimic de care aplicația nu are nevoie pentru a rula. O aplicație C++ construită într-o etapă care conține gcc, make, cmake și antete de dezvoltare produce o imagine finală care conține doar binarul și bibliotecile partajate de rulare ale acestuia.

# Etapa 1: construcție — lanț de instrumente complet, absent din imaginea finală
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)

# Etapa 2: rulare — bază minimă, fără instrumente de construcție
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Utilizator non-root — cerință de întărire STIG și NSA
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

Pentru aplicațiile compilate static în Go sau Rust, etapa finală poate fi scratch — o imagine complet goală care conține doar binarul. Aceasta elimină în totalitate stratul sistemului de operare, eliminând toate vulnerabilitățile la nivel de SO de pe suprafața de descoperire a scanerului. Capacitățile de compilare încrucișată și legare statică ale bibliotecii standard Go fac imaginile scratch practice pentru o gamă largă de microservicii de apărare fără complexitate suplimentară de construcție.

Când aplicația necesită un shell sau utilitare SO la rulare (depanare în dezvoltare, scripturi de verificare a sănătății, logică de inițializare), imaginile gcr.io/distroless oferă un punct intermediar: o bază Debian sau Alpine minimă care conține doar rularea limbajului și biblioteca C, fără shell, fără manager de pachete și fără utilitare de sistem. Imaginile Distroless sunt menținute de Google și publicate cu rezultatele scanării vulnerabilităților; programele de apărare care utilizează distroless ar trebui să oglindească aceste imagini în registrul lor intern și să mențină propriile înregistrări de evaluare a vulnerabilităților.

Aplicarea utilizatorului non-root este o cerință de întărire atât în Ghidul de Întărire Kubernetes al NSA, cât și în STIG. Instrucțiunea USER din Dockerfile setează utilizatorul implicit pentru toate comenzile ulterioare și pentru punctul de intrare al containerului. Utilizați un UID numeric (nu un utilizator cu nume) pentru a evita dependența de fișierul /etc/passwd și alegeți un UID peste 10000 pentru a evita conflictele cu intervalele utilizatorilor de sistem. Controlerele de admitere care aplică profilul restricted Pod Security vor respinge pod-urile unde runAsNonRoot nu este true sau unde un container declară runAsUser: 0.

Scanarea vulnerabilităților în pipeline-uri CI/CD clasificate

Scanarea vulnerabilităților reprezintă poarta de calitate care previne ca imaginile cu CVE-uri exploatabile cunoscute să ajungă la implementările clasificate. Două scannere open-source domină implementările platformelor de containere pentru apărare: Trivy (Aqua Security) și Grype (Anchore). Ambele suportă operarea offline — o cerință non-negociabilă pentru CI/CD în medii de apărare izolate de internet.

Modul offline al Trivy necesită ca baza de date a vulnerabilităților să fie pre-descărcată și transferată în mediul izolat. Baza de date acoperă pachete SO (RPM, DEB, APK), pachete din ecosistemul de limbaj (pip, npm, Maven, module Go, Cargo) și semnături binare ale aplicației. Fluxul de transfer folosind suporturi amovibile sau o soluție cross-domain trebuie integrat în operațiunile regulate ale echipei ca sarcină programată — o bază de date veche (mai veche de 14 zile) este o constatare frecventă în evaluările de securitate ale mediilor clasificate.

# Pe sistemul conectat (cu acces la internet) — descărcați baza de date Trivy
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# Transferați /transfer/trivy-cache pe sistemul izolat prin suport media aprobat

# Pe runner-ul CI/CD izolat — scanați imaginea cu baza de date locală
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...

# Echivalent Grype — dezactivați actualizarea automată, indicați baza de date locală
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

Porțile politicii de scanare definesc care constatări blochează o construcție de pipeline față de cele care generează avertismente. O politică de poartă defensibilă pentru mediile clasificate:

• Blocare (pipeline eșuează, imaginea nu este împinsă): orice CVE cu severitate CRITICAL, orice CVE cu severitate HIGH într-o dependență directă cu un sub-scor de exploatabilitate CVSS peste 7.0 sau un scor EPSS peste 0.05.
• Avertizare și necesitate de derogare: CVE-uri cu severitate HIGH în dependențe tranzitive, CVE-uri cu severitate HIGH unde nu este disponibil niciun patch de la furnizor, CVE-uri cu severitate MEDIUM.
• Doar informațional: constatări LOW și NEGLIGIBLE, CVE-uri care afectează componente demonstrabil inaccesibile în calea de execuție a aplicației.

Fiecare derogare trebuie să fie un document semnat, limitat în timp, care leagă identificatorul CVE, justificarea (niciun patch disponibil, componenta inaccesibilă, control compensator), ofițerul de securitate aprobator și o dată de expirare care declanșează re-evaluarea. Derogările stocate ca fișiere YAML revizuite prin cod în depozitul CI/CD oferă un registru auditabil care satisface cerințele de dovezi ATO.

Semnarea imaginilor cu Cosign/Sigstore în medii deconectate

Semnarea imaginilor oferă dovada criptografică că o imagine de container specifică — identificată prin digest-ul său de conținut SHA-256 — a fost produsă de un pipeline autorizat și nu a fost modificată de la semnare. Cosign (parte din proiectul Sigstore al Linux Foundation) a devenit instrumentul standard de semnare a imaginilor pentru mediile de containere, producând semnături compatibile OCI stocate ca artefacte în același registru ca și imaginea.

Fluxul de semnare fără cheie al Sigstore folosește token-uri de identitate OIDC și infrastructura publică (CA Fulcio și jurnalul de transparență Rekor) pentru a semna imagini fără a gestiona chei private cu viață lungă. Acest model este potrivit pentru CI/CD public open-source, dar necesită acces la internet la infrastructura publică Sigstore — incompatibil cu mediile clasificate izolate de internet. Mediile deconectate au două opțiuni practice:

• Semnare cu cheie (recomandat pentru clasificat). Generați o pereche de chei Cosign; stocați cheia privată într-un HSM sau un manager de secrete aprobat (HashiCorp Vault cu backend validat FIPS, AWS CloudHSM sau Azure Dedicated HSM). Pasul de semnare din pipeline-ul CI/CD recuperează referința cheii și semnează digest-ul imaginii. Cheia publică este distribuită controlerelor de admitere pentru verificare. Nu este necesară infrastructură externă.
• Instanță privată Sigstore. Implementați Fulcio și Rekor în interiorul rețelei clasificate. Aceasta oferă avantajele UX fără cheie și ale jurnalului de transparență, dar necesită operarea unei infrastructuri suplimentare, inclusiv un furnizor de identitate OIDC intern. Potrivit pentru programe mari cu echipe dedicate de inginerie a platformei.

# Generați perechea de chei Cosign (rulați o dată, stocați cheia privată în HSM/Vault)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Semnați imaginea după trecerea porților de scanare — referențiați imaginea prin digest, nu 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}

# Verificați semnătura (folosit de controlerele de admitere și în audituri manuale)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

Aplicarea semnăturii imaginii de către controlorul de admitere închide decalajul dintre semnarea în pipeline și implementarea la rulare. Un ClusterPolicy Kyverno cu o regulă verifyImages respinge orice pod care face referire la o imagine fără o semnătură validă din cheia publică Cosign aprobată. Politica ar trebui să activeze și mutateDigest: true, care rescrie referințele de tag mutabile în referințe de digest imutabile în specificația pod-ului la momentul admiterii — asigurând că rularea containerului extrage exact imaginea care a fost verificată, nu un push ulterior la același tag.

Generarea SBOM pentru pachete ATO

Un Software Bill of Materials (SBOM) este un inventar lizibil de mașină al fiecărei componente software dintr-un artefact implementat — pachete SO, biblioteci de rulare ale limbajului, dependențe ale aplicației și relațiile dintre ele. Pentru pachetele ATO, SBOM oferă ofițerului autorizator vizibilitate asupra lanțului de aprovizionare software al sistemului implementat și reprezintă din ce în ce mai mult un livrabil obligatoriu conform politicii DoD de achiziție software și ghidării CISA care implementează Ordinul Executiv 14028.

Syft (Anchore) este generatorul SBOM open-source standard pentru imaginile de container. Scanează sistemul de fișiere al imaginii strat cu strat, identifică pachetele atât prin înregistrările bazei de date de pachete SO, cât și prin fișierele de blocare ale ecosistemului de limbaj, și produce documente SBOM structurate. Rularea Syft față de digest-ul final al imaginii (nu față de Dockerfile sau depozitul sursă) capturează setul de componente efectiv implementat, inclusiv pachetele instalate tranzitiv sau adăugate în timpul procesului de construcție care nu sunt listate explicit în fișierele de dependențe ale aplicației.

# Generați SBOM în formatele SPDX și CycloneDX din imaginea finală
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# Atașați SBOM la imagine în registru (stocat ca artefact OCI)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# Verificați atașarea SBOM
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

Pe tema SPDX versus CycloneDX: ambele formate sunt acceptate de ghidarea CISA și sunt capabile să reprezinte aceleași informații despre componente. SPDX (ISO/IEC 5962:2021) este standardul mai vechi cu un mandat mai puternic în contextele guvernamentale; CycloneDX are un suport mai bun de instrumente pentru îmbogățirea vulnerabilităților prin documente VEX (Vulnerability Exploitability eXchange). Pentru aplicarea SBOM în pipeline-urile de apărare, generarea ambelor formate dintr-o singură invocare Syft nu costă nimic și asigură compatibilitatea cu orice instrumente ATO din aval sau preferințele ofițerului autorizator.

SBOM-ul transmis ofițerului autorizator ar trebui însoțit de un document de dezvăluire a vulnerabilităților care mapează identificatorii componentelor SBOM la constatările scanării și dispoziția lor (remediate, derogare cu justificare, neafectate). Acest pachet combinat — digest-ul imaginii, SBOM, rezultatele scanării, derogările și semnătura Cosign — formează setul de dovezi ale lanțului de aprovizionare pe care auditorii îl folosesc pentru a evalua fiabilitatea unui sistem implementat.

Securitatea registrului de imagini de container

Harbor este registrul de containere absolvit de CNCF cel mai frecvent implementat în mediile de apărare și clasificate. Setul său de funcții abordează cerințele operaționale specifice ale registrelor de apărare: imutabilitatea tag-urilor, integrarea content trust cu Cosign, controlul accesului bazat pe roluri, integrarea scanării vulnerabilităților (Trivy) și politicile de replicare pentru rețelele de registre cu mai multe enclave. Rularea Harbor într-un mediu clasificat necesită atenție la mai multe domenii de configurare pe care setările implicite nu le aplică.

Imutabilitatea tag-urilor previne ca orice operație de push să suprascrie un tag de imagine existent. Fără acest control, un cont de serviciu CI/CD compromis sau un pipeline configurat greșit ar putea înlocui silențios o imagine aprobată, semnată, cu una malițioasă sau nesemnată sub același tag. Regulile de imutabilitate a tag-urilor din Harbor sunt configurate per-proiect și pot fi limitate la tipare specifice de tag — de exemplu, blocând toate tag-urile care corespund v[0-9]* (versiunile de lansare) permițând în același timp tag-uri mutabile dev-* în proiectele de dezvoltare.

Politica de content trust din Harbor se integrează cu Cosign pentru a aplica verificarea semnăturii la momentul extragerii. Când content trust este activat pentru un proiect, stratul proxy al Harbor apelează cosign verify pentru fiecare solicitare de extragere a imaginii și returnează o eroare de autorizare dacă imaginii îi lipsește o semnătură validă din cheia publică configurată. Aceasta oferă aplicare la nivel de registru, independentă de controlerul de admitere Kubernetes — imaginile nu pot fi extrase chiar și de instrumente care ocolesc webhook-ul de admitere.

# Configurarea proiectului Harbor prin CLI (harbor-cli sau curl față de API-ul Harbor)
# Activați imutabilitatea tag-urilor pentru proiectul de producție
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]*"}]
  }'

# Activați scanarea vulnerabilităților la push pentru toate proiectele
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"}}'

Cache-ul pull-through din Harbor îndeplinește o funcție critică în arhitecturile cu mai multe enclave. Instanța Harbor conectată (clasificare inferioară) este configurată cu proiecte proxy cache care indică registrele externe aprobate (Red Hat Registry, Iron Bank). Pe partea clasificată, o instanță Harbor separată nu are niciun registru din amonte configurat — servește doar imagini care au fost extrase prin cache pe partea conectată, scanate, semnate și transferate fizic la registrul din partea clasificată prin mecanismul aprobat de transfer cross-domain. Aceasta creează un flux de lucru controlat de promovare a imaginilor în care fiecare imagine trebuie să treacă controalele de securitate înainte de a intra în mediul clasificat, nu la intrare.

Politica de colectare a gunoiului din Harbor elimină manifeste fără tag și straturi neutilizate conform unui program definit. În mediile clasificate cu capacitate de stocare limitată, colectarea gunoiului previne creșterea nelimitată a stocării registrului pe măsură ce imaginile sunt înlocuite de versiuni noi. Configurarea recomandată rulează colectarea gunoiului săptămânal în timpul unei ferestre de mentenanță, reține un număr configurabil de imagini cu tag istorice per depozit pentru capacitatea de revenire și generează un jurnal de ștergere pentru auditabilitate. Ștergerea imaginilor într-un registru clasificat trebuie coordonată cu cerințele de retenție a dovezilor ATO — artefactele SBOM și scanare pentru versiunile de imagine implementate pot trebui reținute dincolo de ciclul de viață al imaginii.