Godkjente images
Det skal finnes et lokalt image registry for UiO. Alle applikasjoner og tjenester som benyttes i produksjon m? baseres p? oppdaterte og godkjente base images som hentes herfra. Bruk av images direkte fra offentlige registries som DockerHub er ikke tillatt. Dersom man bygger images selv er det tillatt ? basere disse byggene p? vedlikeholdte images fra Red Hat sin ?container catalog?. Lokalt registry tilbyr et sikkerhetsklarert sett av container images fra eksterne repoer.
Nye images
Hvilke container images og repoer som skal tilbys gjennom lokalt registry vurderes av enheten som skal benytte imaget. Nye images som skal legges inn i lokalt registry skal registreres i et eget nettskjema. R?d fra it-sikkerhet innhentes ved behov.
Det finnes et stort utvalg av container images i Red Hat sin container catalog. Disse er generelt bedre vedlikeholdt enn mange av de images som finnes p? DockerHub. Derfor m? alle som s?ker om innhenting av nye images f?rst sjekke om tilsvarende image finnes der.
Se videre under ?Container Images?
Dockerfiler og merking av applikasjoner
Det skal v?re full sporbarhet p? hvilke artefakter som inng?r i et image som kj?res p? server-nett. Dockerfiler og/eller byggeautomatikk skal ligge i VCS med lesetilgang for organisasjonen og med tilgang til ? opprette pull requests mot repoet. Commit av nye layers er ikke tillatt annet enn i sandkasse-testing, da dette ?delegger sporbarheten. Bruk av lokale filer som legges til m? dokumenteres med referanse til hvor filen kommer fra, og eventuelt hvorfor software repo i base image ikke er brukt. Eksterne filer m? i tillegg til dette som hovedregel lastes ned over https, hvis dette ikke er mulig m? sjekksum p? filen valideres.
Alle applikasjoner som kj?rer i containere m? ha en kontaktadresse i Docker-filen. Kontaktadressen skal settes i labelen ?no.uio.contact? og kan eksempelvis v?re e-postlisten til gruppen eller applikasjonen. Alle images m? ogs? merkes/?lables? med gruppe/applikasjonsnavn. Dette for ? sikre at ingen applikasjoner kj?rer uten en ansvarlig eier. I tillegg til dette skal det v?re en tydelig relasjon mellom versjonen av applikasjonens Dockerfile og image i registry, dette gj?res ved bruk av docker tags.
Secrets
Hemmeligheter som benyttes i applikasjonen skal ikke inkluderes i selve Docker-fil eller Docker images, men legges til p? en sikker m?te under oppstart av containeren. IT-Sikkerhet kan bist? med risikovurdering i forbindelse med bruk av hemmeligheter i applikasjonen. Hemmeligheter i applikasjoner skal behandles p? samme m?te som passord, og skal skiftes minst én gang i ?ret.
Logging
Containere som kj?rer i produksjon skal logge container output til ELK via journald. Utover dette logger hver enkelt applikasjon som vanlig basert p? krav om audit log, aksesslogg med mer.
Oppdateringer av container-images og s?rbarheter
S?rbarheter i container-images
Images i lokalt registry skal regelmessig scannes for s?rbarheter med eget analyseverkt?y som holder oversikt over hva som er installert i de ulike lagene til imaget, og hvilke s?rbarheter som finnes.
S?rbarheter i kj?rende containere og applikasjoner
En oversikt over alle container images som kj?rer fra containere skal samles inn til en sentral lokasjon og det skal automatisk lages rapporter til applikasjonseiere over hvilke instanser som kj?rer med potensielt s?rbare image layers. Ansvarlige for applikasjonen er ogs? ansvarlige for at applikasjonen kj?rer p? et oppdatert base image, og at s?rbare applikasjoner oppdateres basert p? rapport om s?rbarheter samt en egen vurdering basert p? kjennskap til applikasjonen. IT-Sikkerhet er ansvarlige for ? p?se at rapporter om s?rbarheter f?lges opp. Oppdatering av images for kj?rende containere skal minimum skje én gang i m?neden. Bygging og redeployment av containere b?r i st?rst mulig grad automatiseres. Det vil bli sendt ut rapporter som informerer om kj?rende tjenester som avviker fra policy. Det er tjenesteeier sitt ansvar ? f?lge opp avvikene i samr?d med it-sikkerhet.
Bygging av applikasjons-images
Applikasjons-images kan bygges p?, og pushes fra, alle godkjente server- og klientplatformer ved UiO. For ? redusere angrepsflaten mot applikasjoner som kj?rer i containere b?r applikasjonsimaget bygges s? minimalistisk som mulig og unng? ? trekke med seg un?dvendige avhengigheter. Et effektivt virkemiddel her er ? bruke et minimalt base image. I skrivende stund er Alpine Linux og Busybox eksempler p? slike base images.
Kj?ring av containere
Leveranse av containerbaserte produksjonstjenester gj?res p? godkjent runtime-milj? for containere. Dette er i dag RHEL7-server (og nyere) med standard driftsopplegg og godkjent sentral kubernetes-/openshift-l?sning Det er kun tillatt ? bruke byggeverkt?y og container runtimes som er tilgjengelig gjennom Red Hats programvare-kilder. Andre versjoner er tillatt i nedstengte sandkassemilj?er. Kravet er begrunnet med at RHEL7 f?lger standard driftsopplegg for Linux-servere med daglig oppdatering av pakker, i tillegg er rammeverk p? RHEL7 automatisk beskyttet av SELinux. Dette gir en h?yere grad av isolering enn container-hoster uten ?mandatory access control?.