Kontainer-kuvasuojaus puolustuskäyttöön: koventaminen, skannaus ja toimitusketjun eheys

Kontainer-kuvat ovat modernin puolustusohjelmiston toimituksen atomiyksikkö. Jokainen Kubernetes-puolustusklustereilla suoritettava työkuorma — tehtäväsovellukset, datapipelinit, tekoälyinferenssipalvelut — saapuu muuttumattomana kuvana, joka on rakennettu jossain, jostakin. Kaiken tämän jälkeisen tietoturva riippuu kyseisen rakennusketjun eheydestä. Yritysympäristöissä vaarantunut kontainer-kuva on vakava tietoturvapoikkeama. Luokitellussa puolustusympäristössä se on potentiaalinen tiedustelutiedon keräämiskanava, kansallisvaltiota edustavan toimijan pysyvyysjärjestelmä tai asejärjestelmiin kohdistuvien tuhoavien kyvykkyyksien sisäänpääsypiste.

Tässä artikkelissa käsitellään koko kontainer-kuvan tietoturvan elinkaari puolustuskäyttöön: STIG-yhteensopivien pohjakuvien valinta ja vahvistaminen, rakentamisen koventaminen monivaiheisilla Dockerfileillä, haavoittuvuusskannaus ilmarakoerotetuissa CI/CD-pipelineissä, kuvien allekirjoittaminen Cosign/Sigstorella verkottomissa ympäristöissä, SBOMien luominen ATO-paketteja varten sekä rekisterin eheysohjausten valvonta Harborissa. Kohderyhmänä ovat alustatekniikan insinöörit ja tietoturva-arkkitehdit, jotka työskentelevät luokiteltujen tai arkaluonteisten puolustusjärjestelmien parissa.

Miksi kontainer-kuvan tietoturva on tärkeämpää puolustuksessa kuin yritysmaailmassa

Kaupallisessa yrityksessä haavoittuvainen tai vaarantunut kontainer-kuva merkitsee tietomurtoriskin, operatiivisen häiriön ja sääntelyvelvoitteiden laiminlyönnin. Luokitellussa puolustusympäristössä seuraukset ulottuvat lähteiden ja menetelmien paljastumiseen, tehtävän vaarantumiseen sekä kineettisiin vaikutuksiin järjestelmissä, joita ohjelmistohaavoittuvuus saattaa antaa vastustajalle mahdollisuuden hallita tai poistaa käytöstä. Uhkamalli on laadullisesti erilainen: vastustaja ei ole taloudellisesti motivoitunut rikollisryhmä vaan kansallisvaltio, jolla on jatkuva pääsytoiminto ja kärsivällisyys odottaa vuosia oikeaa hetkeä aktivoida istutettu kyvykkyys.

Kontainerin toimitusketjuhyökkäykset hyödyntävät kontainer-kuvien kerrostettua luonnetta. Tyypillinen tehtäväsovelluksen kuva saatetaan rakentaa FROM-pohjakäyttöjärjestelmäkuvasta, joka asentaa ajonaikaiset paketit pakettivarastosta, joka puolestaan sisältää transitiivisia riippuvuuksia, jotka haetaan rakennusaikana ylävirtaisista kielipakettirekistereistä. Vastustajan ei tarvitse vaarantaa puolustusurakoitsijan sisäisiä järjestelmiä — kolme tasoa syvemmällä ketjussa olevan riippuvuuden vaarantaminen saavuttaa saman vaikutuksen. SolarWinds- ja XZ Utils -tapaukset osoittivat, että tämä uhkamalli ei ole teoreettinen; molemmat olivat toimitusketjun lisäyksiä, jotka olisivat olleet teknisesti havaitsemattomissa ilman syviä toimitusketjun ohjauksia.

Puolustusympäristöt lisäävät kolme vaatimusta, jotka tekevät kontainer-kuvan tietoturvasta operatiivisesti huomattavasti monimutkaisempaa kuin yritysympäristöissä:

• Ilmarakovaatimukset. Luokitellut verkot eivät voi hakea kuvia internet-rekistereistä ajon aikana. Jokainen kuvariippuvuus on ennalta hyväksyttävä, ennalta skannattava ja peilattava sisäiseen rekisteriin ennen käyttöönottoa — mikä tarkoittaa, että toimitusketjun raja on kova kehä, jonka suunnittelutiimit täysin omistavat ja vastaavat sen valvonnasta.
• Muodolliset hyväksyntävaatimukset. Luokitelluilla järjestelmillä suoritettavan ohjelmiston on läpäistävä toimintavaltuutusprosessi (ATO), joka vaatii dokumentoitua alkuperätietoa jokaisesta ohjelmistokomponentista. SBOM-luonti ja kuvan allekirjoittaminen siirtyvät valinnaisista hygieniatoimenpiteistä pakollisiksi ATO-todistusaineistotoimitettaviksi.
• Muuttumattoman infrastruktuurin valvonta. Puolustusalustat edellyttävät yhä enemmän, ettei kontainer-kuvien ajonaikaista muokkausta sallita: kontainerit tuhotaan ja korvataan, eikä niitä koskaan korjata paikallaan. Tämä tarkoittaa, että käyttöönotetun työkuorman tietoturva-asento asetetaan pysyvästi kuvan rakennushetkellä, mikä tekee rakennusajan koventamisesta ja skannauspaskeista neuvottelemattomia eikä parhaan yrityksen asioita.

STIG-yhteensopivat pohjakuvat

DISA (Defense Information Systems Agency) julkaisee Security Technical Implementation Guides (STIG) -oppaita puolustusympäristöissä käytetyille käyttöjärjestelmille ja alustoille. Kontainerisoitujen työkuormien osalta operatiivisesti merkittävimmät ovat RHEL 8 STIG ja RHEL 9 STIG, jotka koskevat Red Hat Universal Base Image (UBI) -johdannaisia — yleisimmin käytettyjä pohjakuvia puolustuksen kontainerialustoilla, mukaan lukien DoD Platform Onen Iron Bank -kovennettu kuvavarasto.

RHEL STIG valvoo ohjauksia useissa kategorioissa, jotka eroavat olennaisesti oletuskäyttöjärjestelmäasennuksesta:

• Ytimen parametrit (sysctl). IP-reititys poistettu käytöstä oletuksena (net.ipv4.ip_forward=0), ICMP-uudelleenohjaukset hylätty, TCP SYN -evästeet käytössä ja satunnaistettu virtuaaliosoiteavaruus (ASLR) pakotettuna. Nämä ohjaukset vähentävät käyttöjärjestelmän altistumista verkkovälittäjänä ja tekevät muistin hyväksikäytöstä vaikeampaa.
• PAM-konfiguraatio. Salasanan monimutkaisuussäännöt (vähimmäispituus, merkkiluokat), tilin lukitseminen epäonnistuneiden todennusyritysten jälkeen ja istunnon tallennusvaatimukset. Avain- tai token-pohjaista todennusta käyttäville kontaineripalvelutileille osa näistä ohjauksista saattaa vaatia dokumentoituja poikkeuksia.
• auditd-säännöt. STIG määrittää kattavan joukon auditd-sääntöjä, jotka kattavat tiedostojärjestelmän pääsyn arkaluonteisiin polkuihin, etuoikeuksien korotuskomennot (sudo, su), käyttäjä- ja ryhmätietokantojen muokkauksen, verkon konfigurointiin tehdyt muutokset sekä ytimen moduulien lataamisen. Kontainerikontekstissa auditd suoritetaan tyypillisesti isäntäytimessä ja koskee kaikkia kontainereita — STIG-säännöt tulisi soveltaa solmutasolla, ei kontainerikohtaisesti.
• FIPS 140 -salauskäytäntö. STIG edellyttää, että järjestelmänlaajuinen salauskäytäntö asetetaan FIPS- tai FIPS:OSCP-tilaan, mikä poistaa käytöstä TLS 1.0/1.1, MD5:n, SHA-1:n allekirjoituksiin, RC4:n ja DES/3DES:n. Vanhentuneisiin algoritmeihin riippuvaiset sovelluskomponentit epäonnistuvat FIPS-salauskäytännön alla — tämä on yleinen integraatio-ongelma, joka havaitaan myöhäisessä koventamisprojektin vaiheessa, kun STIG-pohjakuvaa validoidaan sovellustestauspaketteja vastaan.

Iron Bank (Platform Onen kovennettu kontainerirekisteri) julkaisee esikovennettuja kuvia, jotka on validoitu DISA STIG -ohjeistusta vastaan, skannattu haavoittuvuuksien varalta ja allekirjoitettu. Ohjelmille, jotka ovat jo Platform Onessa, rakentaminen Iron Bank -pohjakuvasta on käytännöllisin lähestymistapa: se tarjoaa dokumentoidun, esiautorisoivan lähtötason, joka täyttää useimpien ATOjen pohjakuvavaatimukset. Ohjelmille, jotka eivät ole Platform Onessa, STIG-vaatimustenmukaisuuden rakentaminen ja validointi itsenäisesti OpenSCAPia (oscap-docker tai oscap vietyä kontaineritiedostojärjestelmää vastaan) käyttäen on vastaava prosessi.

# Validate a container image filesystem against the RHEL 9 STIG
# Export the image filesystem to a temporary directory
docker export $(docker create registry.example.mil/myapp:v1.2.3) | tar -C /tmp/image-fs -xf -

# Run OpenSCAP against the exported filesystem
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

Monivaiheisen rakentamisen koventaminen

Monivaiheinen Docker-rakentaminen on tehokkain yksittäinen tekniikka kontainer-kuvan hyökkäuspinnan pienentämiseen. Periaate on yksinkertainen: käytetään yhtä tai useampaa välivaihetta, jotka sisältävät kaikki sovelluksen kääntämiseen ja paketoimiseen tarvittavat työkalut, ja kopioidaan vain käännetyt artefaktit lopulliseen ajonaikaiseen vaiheeseen, joka ei sisällä mitään, mitä sovellus ei tarvitse toimiakseen. C++-sovellus, joka rakennetaan vaiheessa, joka sisältää gcc:n, maken, cmake:n ja kehitsotsikkotiedostot, tuottaa lopullisen kuvan, joka sisältää vain binäärin ja sen ajonaikaiset jaetut kirjastot.

# Stage 1: build — full toolchain, not present in final image
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)

# Stage 2: runtime — minimal base, no build tools
FROM registry.mil/ironbank/redhat/ubi/ubi9-micro:latest
COPY --from=builder /build/bin/myapp /usr/local/bin/myapp
# Non-root user — STIG and NSA hardening requirement
RUN useradd -r -u 10001 -s /sbin/nologin appuser
USER 10001
EXPOSE 8443
ENTRYPOINT ["/usr/local/bin/myapp"]

Staattisesti käännetyille Go- tai Rust-sovelluksille lopullinen vaihe voi olla scratch — täysin tyhjä kuva, joka sisältää vain binäärin. Tämä poistaa käyttöjärjestelmäkerroksen kokonaan, poistaen kaikki käyttöjärjestelmätason haavoittuvuudet skannerin löydöspinnalta. Go-standardikirjaston ristikääntämis- ja staattisen linkityksen kyvykkyydet tekevät scratch-kuvista käytännöllisiä laajalle joukolle puolustuksen mikropalveluita ilman lisärakennuksen monimutkaisuutta.

Kun sovellus vaatii kuoren tai käyttöjärjestelmäapuohjelmia ajon aikana (virheenkorjaus kehityksessä, terveystarkistuskomentosarjat, alustuslogiikka), gcr.io/distroless -kuvat tarjoavat välivaihtoehdon: minimaalinen Debian- tai Alpine-pohja, joka sisältää vain kieliajoympäristön ja C-kirjaston, ilman kuorta, paketinhallintaa tai järjestelmäapuohjelmia. Distroless-kuvia ylläpitää Google ja ne julkaistaan haavoittuvuusskannaustulosten kanssa; puolustusohjelmat, jotka käyttävät distrolessia, tulee peilata nämä kuvat sisäiseen rekisteriinsä ja ylläpitää omia haavoittuvuusarviointitietojaan.

Ei-juurikäyttäjän valvonta on koventamisvaatimus sekä NSA Kubernetes Hardening Guide -oppaassa että STIGissä. USER-ohje Dockerfilessä asettaa oletuskäyttäjän kaikille myöhemmille komennoille ja kontaineriin sisäänpääsypisteelle. Käytä numeerista UID:tä (ei nimettyä käyttäjää) välttääksesi riippuvuuden /etc/passwd-tiedostosta ja valitse UID yli 10000:n välttääksesi ristiriitoja järjestelmäkäyttäjäalueiden kanssa. Admission-kontrollereita, jotka valvovat Pod Security restricted -profiilia, hylkäävät podit, joissa runAsNonRoot ei ole tosi tai joissa kontaineri julistaa runAsUser: 0.

Haavoittuvuusskannaus luokitelluissa CI/CD-pipelineissä

Haavoittuvuusskannaus on laadunvarmistusportti, joka estää tunnetuilla hyödynnettävillä CVE-haavoittuvuuksilla varustettujen kuvien pääsyn luokiteltuihin käyttöönottokohteisiin. Kaksi avoimen lähdekoodin skanneria hallitsee puolustuksen kontainerialustasovellusten toteutuksia: Trivy (Aqua Security) ja Grype (Anchore). Molemmat tukevat offline-toimintaa — ehdoton vaatimus ilmarakoerotettujen puolustusympäristöjen CI/CD:lle.

Trivyn offline-tila edellyttää, että haavoittuvuustietokanta on ladattu ennalta ja siirretty ilmarakoerotettuun ympäristöön. Tietokanta kattaa käyttöjärjestelmäpaketit (RPM, DEB, APK), kielikosysteemipaketit (pip, npm, Maven, Go-moduulit, Cargo) ja sovellusbinäärien allekirjoitukset. Irrotettavaa mediaa tai cross-domain-ratkaisua käyttävä siirtoprosessi on integroitava tiimin säännölliseen toimintaan aikataulutettuna tehtävänä — vanhentunut tietokanta (yli 14 päivää vanha) on yleinen löydös luokiteltujen ympäristöjen tietoturva-arvioinneissa.

# On connected (internet-facing) system — download Trivy DB
trivy image --download-db-only --cache-dir /transfer/trivy-cache

# Transfer /transfer/trivy-cache to air-gapped system via approved media

# On air-gapped CI/CD runner — scan image with local DB
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...

# Grype equivalent — disable auto-update, point to local DB
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

Skannauskäytäntöportit määrittävät, mitkä löydökset estävät pipeline-rakennuksen varrinkaan varoituksia. Puolustettava porttikäytäntö luokitelluille ympäristöille:

• Estä (pipeline epäonnistuu, kuvaa ei lähetetä): mikä tahansa CRITICAL-vakavuuden CVE, mikä tahansa HIGH-vakavuuden CVE suorassa riippuvuudessa, jonka CVSS-hyödynnettävyysosa-pisteet ovat yli 7,0 tai EPSS-pisteet yli 0,05.
• Varoita ja vaadi poikkeuslupa: HIGH-vakavuuden CVEt transitiivisissa riippuvuuksissa, HIGH-vakavuuden CVEt joihin ei ole saatavilla toimittajan korjausta, MEDIUM-vakavuuden CVEt.
• Vain tiedoksi: LOW- ja NEGLIGIBLE-löydökset, CVEt, jotka vaikuttavat komponentteihin, jotka eivät osoitettavasti ole sovelluksen suorituspolun tavoitettavissa.

Jokaisen poikkeusluvan on oltava allekirjoitettu, aikarajoitettu asiakirja, joka linkittää CVE-tunnisteen, perustelun (ei korjausta saatavilla, komponentti ei tavoitettavissa, kompensoiva ohjaus), hyväksyvän tietoturvatoimiston ja vanhentumispäivän, joka käynnistää uudelleenarvioinnin. Koodikatselmoiduina YAML-tiedostoina CI/CD-varastossa tallennetut poikkeusluvat tarjoavat auditoitavan tietueen, joka täyttää ATO-todistusaineistovaatimukset.

Kuvan allekirjoittaminen Cosign/Sigstorella verkottomissa ympäristöissä

Kuvan allekirjoittaminen tarjoaa kryptografisen todisteen siitä, että tietty kontainer-kuva — tunnistettu sen SHA-256-sisältötiivisteellä — on tuotettu valtuutetulla pipelinellä eikä sitä ole muutettu allekirjoituksen jälkeen. Cosign (osa Linux Foundationin Sigstore-projektia) on tullut standardiksi kuvan allekirjoitustyökaluksi kontaineriympäristöissä tuottaen OCI-yhteensopivia allekirjoituksia, jotka tallennetaan artefakteina samassa rekisterissä kuin kuva.

Sigstoren avaimeton allekirjoitusvirtaus käyttää OIDC-identiteettitokeneja ja julkista infrastruktuuria (Fulcio CA ja Rekor-läpinäkyvyysloki) kuvien allekirjoittamiseen ilman pitkäikäisten yksityisten avainten hallintaa. Tämä malli sopii hyvin julkiseen avoimen lähdekoodin CI/CD:hen, mutta vaatii internet-yhteyden Sigstoren julkiseen infrastruktuuriin — yhteensopimaton ilmarakoerotettujen luokiteltujen ympäristöjen kanssa. Verkottomilla ympäristöillä on kaksi käytännöllistä vaihtoehtoa:

• Avainpohjainen allekirjoittaminen (suositellaan luokitelluille). Luodaan Cosign-avainpari; yksityinen avain tallennetaan HSM:ään tai hyväksyttyyn salauspalveluun (HashiCorp Vault FIPS-validoidulla taustajärjestelmällä, AWS CloudHSM tai Azure Dedicated HSM). CI/CD-pipelinen allekirjoitusvaihe hakee avainviitteen ja allekirjoittaa kuvan tiivisteen. Julkinen avain jaetaan admission-kontrollereille vahvistamista varten. Ulkoista infrastruktuuria ei tarvita.
• Yksityinen Sigstore-instanssi. Fulcion ja Rekorin ottaminen käyttöön luokitellussa verkossa. Tämä tarjoaa avaimettomat UX- ja läpinäkyvyyslokin edut, mutta vaatii lisäinfrastruktuurin käyttämistä, mukaan lukien sisäinen OIDC-identiteettitarjoaja. Sopiva suurille ohjelmille, joilla on omistautuneita alustatekniikan tiimejä.

# Generate Cosign key pair (run once, store private key in HSM/Vault)
cosign generate-key-pair --kms awskms:///arn:aws:kms:us-gov-east-1:123456789:key/abc-def

# Sign image after scanning gates pass — reference image by digest, not 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}

# Verify signature (used by admission controllers and in manual audits)
cosign verify \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  registry.classified.mil/myapp@sha256:abc123...

Admission-kontrollerin kuvan allekirjoitusten valvonta sulkee aukon pipeline-allekirjoittamisen ja ajonaikaisen käyttöönoton välillä. Kyverno ClusterPolicy verifyImages-säännöllä hylkää jokaisen podin, joka viittaa kuvaan ilman voimassa olevaa allekirjoitusta hyväksytyllä Cosign-julkisella avaimella. Käytännön tulisi myös ottaa käyttöön mutateDigest: true, joka kirjoittaa muuttuvat tagviittaukset muuttumattomiksi tiiviste-viittauksiksi podin spesifikaatiossa admission-aikana — varmistaen, että kontaineriajoympäristö hakee täsmälleen sen kuvan, joka vahvistettiin, eikä myöhempää samantagista lähetystä.

SBOM-luonti ATO-paketteja varten

Software Bill of Materials (SBOM) on koneluettava inventaario kaikista ohjelmistokomponenteista käyttöönotetulla artefaktilla — käyttöjärjestelmäpaketeista, kieliajoympäristökirjastoista, sovellusriippuvuuksista ja niiden välisistä suhteista. ATO-paketteja varten SBOM tarjoaa valtuuttavalle viranomaiselle toimitusketjun näkyvyyden käyttöönotettuun järjestelmään ja on yhä useammin pakollinen toimitettava DoD:n ohjelmistohankintakäytännön ja CISA:n toimeenpanomääräyksen 14028:n toteuttamisohjeistuksen mukaisesti.

Syft (Anchore) on standardiavoimen lähdekoodin SBOM-generaattori kontainer-kuville. Se skannaa kuvan tiedostojärjestelmän kerros kerrokselta, tunnistaa paketit sekä käyttöjärjestelmän pakettitietokantatietueista että kielikosysteemien lukitustiedostoista ja tuottaa jäsennellyt SBOM-asiakirjat. Syftin suorittaminen lopullisen kuvan tiivistettä vastaan (ei Dockerfileä tai lähdevarastoa) kaappaa todellisen käyttöönotetun komponenttijoukon, mukaan lukien paketit, jotka on asennettu transitiivisesti tai lisätty rakennusprosessin aikana ilman, että niitä on nimenomaisesti lueteltu sovelluksen riippuvuustiedostoissa.

# Generate SBOM in both SPDX and CycloneDX formats from final image
syft registry.classified.mil/myapp@sha256:abc123... \
  -o spdx-json=/artifacts/sbom.spdx.json \
  -o cyclonedx-json=/artifacts/sbom.cdx.json

# Attach SBOM to the image in the registry (stored as OCI artifact)
cosign attach sbom \
  --sbom /artifacts/sbom.spdx.json \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

# Verify SBOM attachment
cosign verify-attestation \
  --key /etc/cosign/cosign.pub \
  --insecure-ignore-tlog=true \
  --type spdx \
  registry.classified.mil/myapp@sha256:abc123...

SPDX versus CycloneDX -kysymyksessä: molemmat formaatit ovat CISA:n ohjeistuksen hyväksymiä ja kykenevät edustamaan samoja komponenttitietoja. SPDX (ISO/IEC 5962:2021) on vanhempi standardi, jolla on vahvempi toimeksianto hallinnollisissa yhteyksissä; CycloneDX:llä on vahvempi työkalutuki haavoittuvuuden rikastamiseen VEX (Vulnerability Exploitability eXchange) -asiakirjojen kautta. SBOM-valvontaa puolustuksen pipelinesissa varten molempien formaattien luominen yhdellä Syft-kutsulla ei maksa mitään ja varmistaa yhteensopivuuden minkä tahansa alajuoksen ATO-työkalun tai valtuuttavan viranomaisen mieltymyksen kanssa.

AO:lle toimitetun SBOMin tulee olla mukana haavoittuvuuden paljastusasiakirja, joka kartoittaa SBOM-komponenttitunnisteet skannauslöydöksiin ja niiden käsittelyyn (korjattu, poikkeusluvalla perusteluna, ei vaikuta). Tämä yhdistetty paketti — kuvan tiiviste, SBOM, skannauksen tulokset, poikkeusluvat ja Cosign-allekirjoitus — muodostaa toimitusketjun todistusaineiston, jota auditoijat käyttävät arvioidessaan käyttöönotetun järjestelmän luotettavuutta.

Kontainer-kuvarekisterin tietoturva

Harbor on CNCF:n valmistunut kontainerirekisteri, joka on laajimmin käyttöönotettu puolustus- ja luokitelluissa ympäristöissä. Sen ominaisuusjoukko käsittelee puolustusrekisterien erityiset operatiiviset vaatimukset: tagin muuttamattomuus, sisältöluottamuksen integrointi Cosignin kanssa, roolipohjainen pääsynhallinta, haavoittuvuusskannauksen integrointi (Trivy) ja replikointikäytännöt monienklaavisen rekisteriverkon rakentamiseen. Harborin käyttäminen luokitellussa ympäristössä edellyttää huomiota useisiin konfiguraatioalueisiin, joita oletusasetukset eivät valvo.

Tagin muuttamattomuus estää lähetysoperaatioita ylikirjoittamasta olemassa olevia tageja. Ilman tätä ohjausta vaarantunut CI/CD-palvelutili tai virheellisesti konfiguroitu pipeline voisi hiljaisesti korvata hyväksytyn, allekirjoitetun kuvan haitallisella tai allekirjoittamattomalla samalla tagilla. Harborin tagin muuttamattomuussäännöt konfiguroidaan projektikohtaisesti ja ne voidaan rajata tiettyihin tagimalleihin — esimerkiksi lukitsemalla kaikki v[0-9]*:ta vastaavat tagit (julkaisuversiot) samalla kun sallitaan muuttuvat dev-*-tagit kehitysprojekteissa.

Sisältöluottamuskäytäntö Harborissa integroituu Cosignin kanssa allekirjoitusten vahvistamisen valvomiseksi hakuhetkellä. Kun sisältöluottamus on aktivoitu projektille, Harborin välityskerros kutsuu Cosign verifyä jokaiselle kuvanhakupyynnölle ja palauttaa valtuutusvirheen, jos kuvasta puuttuu voimassa oleva allekirjoitus konfiguroidulta julkiselta avaimelta. Tämä tarjoaa rekisteritason valvonnan riippumatta Kubernetes-admission-kontrollerista — kuvia ei voida hakea edes työkaluilla, jotka ohittavat admission-webhookin.

# Harbor project configuration via CLI (harbor-cli or curl against Harbor API)
# Enable tag immutability for production project
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]*"}]
  }'

# Enable vulnerability scanning on push for all projects
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"}}'

Läpimenevä välimuisti Harborissa palvelee kriittistä funktiota monienklaaviarkkitehtuureissa. Yhdistetty (alemman luokituksen) Harbor-instanssi konfiguroidaan ylävirran välitysvälimuistiprojekteilla, jotka osoittavat hyväksyttyihin ulkoisiin rekistereihin (Red Hat Registry, Iron Bank). Luokitellulle puolelle erillisellä Harbor-instanssilla ei ole konfiguroitua ylävirran rekisteriä — se palvelee vain kuvia, jotka on haettu yhdistetyn puolen välimuistin kautta, skannattu, allekirjoitettu ja fyysisesti siirretty luokitellulle puolelle hyväksytyn cross-domain-siirtomekanismin kautta. Tämä luo hallitun kuvan ylentämistyönkulun, jossa jokaisen kuvan on läpäistävä tietoturvohjaukset ennen luokiteltuun ympäristöön siirtymistä eikä vasta siellä.

Roskienkeruukäytäntö Harborissa poistaa tagimattomat manifestit ja käyttämättömät kerrokset määritetyn aikataulun mukaan. Luokitelluissa ympäristöissä, joissa on rajallinen tallennuskapasiteetti, roskienkeruu estää rekisterin tallennuksen kasvamisen rajattomasti kuvien korvautuessa uusilla versioilla. Suositeltu konfiguraatio suorittaa roskienkeruun viikoittain huoltoikkunan aikana, säilyttää konfiguroitavan määrän historiallisia tagattuja kuvia repositoriota kohden palautusmahdollisuuden vuoksi ja tuottaa poistolokin auditointia varten. Kuvan poistaminen luokitellussa rekisterissä on koordinoitava ATO-todistusaineiston säilytysvaatimusten kanssa — käyttöönotettujen kuvaversioiden SBOM- ja skannausartefaktit on ehkä säilytettävä kuvan elinkaaren yli.