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».