Sikring av containerbaserte tjenester

Godkjente images

Det skal finnes et lokalt image-registry for UiO. Alle applikasjoner og tjenester må baseres på oppdaterte og godkjente baseimages som hentes herfra. Bruk av images direkte fra offentlige registries som DockerHub er ikke tillatt. Lokalt registry tilbyr et sikkerhetsklarert sett av Dockerimages fra repoer på DockerHub. 

Nye images

Hvilke containermages 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.

Tilgjengelige images i RedHat container katalog og dokumentasjon finnes på https://access.redhat.com/documentation/en-us/red_hat_software_collections/

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 pakkebrønnen i baseimaget 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 Dockerfilen. 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 Dockerfil eller Dockerimages, 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 en gang i året.

Logging

Dockerimages som kjører skal logge containeroutput 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

Alle container-images som er i bruk til tjenester i prod skal bygges, lastes opp (push) til registry, lastes (pull) og restartes på nytt minst en gang i måneden. Ingen containere skal kjøre images som er bygget for mer enn en måned siden. Dette for å sikre en grunnleggende basis for eksponering av sårbare tjenester.

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årbaheter 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 sårbare image layers.  Ansvarlige for applikasjonen er også ansvarlige for at applikasjonen kjører på et oppdatert baseimage, 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 minumim skje en 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 seksjon.

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 baseimage. I skrivende stund er Alpine Linux og Busybox eksempler på slike baseimages.

Kjøring av containere

Leveranse av containerbaserte produksjonstjenester gjøres på godkjent runtime-miljø for docker. Dette er i dag RHEL7-server med standard driftsopplegg og godkjent sentral kubernetes-/openshift-løsning Det er kun tillatt å bruke byggeverktøy og container runtimes som er tilgjengelig gjennom RedHat's 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 docker hoster uten «mandatory access control».

 

Publisert 2. apr. 2017 20:31 - Sist endret 1. feb. 2019 12:42