Innhold:
- 1 Hva er Harbor?
- 2 Hvor kj?rer Harbor?
- 3 Retningslinjer for Docker-images
- 4 Brukerh?ndtering og rettigheter i Harbor
- 5 Legge inn nye images fra DockerHub p? harbor
- 6 Sikkerhetsskanning av imager
- 7 Logge inn i Harbor
- 8 Bruk av Harbor
- 9 Fra utvikling til produkjon
1 Hva er Harbor?
VMwares Harbor, et Opensource produkt fra VMware, er et docker-registry. Videre er et docker-registry der en gruppe laster opp, og senere ned, sine docker image. Typisk bygger man et docker image som kj?rer en tjeneste. Dette imaget laster man s? opp til harbor, for s? ? laste det ned til en utvikling, test eller produksjonsserver, for s? ? kj?re tjenesten.
VMware har selvsagt en mer utfyllende dokumentasjon rundt Harbor. For sp?rsm?l som ikke er besvart her kan det v?re verdt ? ta en titt i deres dokumentasjon.
2 Hvor kj?rer Harbor?
I skrivende stund (2018-01-04) kj?re harbor p? harbor03.uio.no.
3 Retningslinjer for Docker-images
Vi har klare retningslinjer for bruk av docker p? UiO. Disse er beskrevet i sikkerhetsh?ndboken under prosedyrer LSIS-dokumentene under tillegg. Det er flere ting som er verdt ? merke seg her, men i v?r sammenheng m? man forholde seg til f?lgende punkter:
- Det er kun lov ? benytte imager fra v?rt registry.
- Nye images som skal legges inn i lokalt registry skal registreres i et eget nettskjema.
- Docker commit er ikke tillatt annet enn ved sandkassebruk. Alts? skal imager som legges i registry bygges fra en Dockerfile.
- Alle applikasjoner som kj?rer i containere m? ha en kontaktadresse i Dockerfilen. Dette kan eksempelvis v?re e-postlisten til gruppen eller applikasjonen. Tidligere var dette satt med MAINTAINER-labelen, og den m? gjerne fortsatt brukes, men i tillegg er det et krav at man ogs? setter labelen no.uio.contact med en e-postliste.
- Alle images m? ogs? merkes/?lables? med gruppe/applikasjonsnavn.
- Hemmeligheter som benyttes i applikasjonen skal ikke inkluderes i selve Dockerfile eller Dockerimages.
4 Brukerh?ndtering og rettigheter i Harbor
Vi ?nsker ? bruke LDAP for innlogging og rettighetsstyring. Ut fra erfaring med harbor02, der vi satte opp manuelle grupper, s?g vi at antallet bruken bare vokste og administrasjon av brukere ble for tidkrevende. Med LDAP kan brukere logge inn med sin driftsbruker, for de som har det. For kunder uten driftsbrukere f?r vanlige brukere tilgang.
Med ldap-grupper blir passordbytte overholdt av Cerebrum. Skrive- og leserettigheter blir styrt av gruppetilh?righeten til brukeren. LDAP-gruppe skal v?re p? formen harbor-<prosjektnavn-iharbor>. Da blir alle brukere i respektive ldapgruppe synkronsisert inn som medlemmer av prosjektet i harbor. Ny gruppe harbor-XXXX kan bestilles hos cerebrum-drift@usit.uio.no. Denne m? ha spread NIS_ng@UIO for ? virke med synkroniseringen. Husk ogs? p? ? legge ved en beskrivelse av hva gruppen skal brukes til i bestillingen. (tilgangsstyring til prosjekt XXX i hrabor.uio.no f.eks.)
Siden alle imager skal bygges fra en Dockerfile, s? er det gjerne naturlig ? gj?re dette automatisk med verkt?y som Jenkins, Ansible etc. I den sammenheng b?r brukergruppene benytte en systembruker for dette form?let. Bestilling av systembrukere gj?res hos Cerebrum. Brukeren skal ha navn p? formatet harbor-<gruppenavn>, f.eks harbor-gid. Gruppen man benytter i harbor b?r gjerne derfor ikke ha privilegier i andre systemer der samme systembruker da kan misbrukes.
4.1 Rettigheter
En gruppe vil f? admin-rettigheter til sitt eget prosjekt. Det inneb?rer at de kan opprette, oppdatere og slette imager innenefor prosjektet. I tillegg vil alle grupper f? leserettigheter til "rot"-prosjektet som heter "library". Det er i "library" imagene som er henter fra DockerHub vil ligge.
Om man ?nsker ? dele sine image med andre vil dette ogs? v?re mulig.
5 Legge inn nye images fra DockerHub p? harbor
Om man ikke finner det imaget man trenger i v?rt registry kan man be om at et image fra DockerHub gj?res tilgjengelig. Bestiller m? da gj?re en vurdering av imaget p? forh?nd, med tanke p? sikkerhet, drift og vedlikehold. Bestillingen gj?res via nettskjema, som sender bestillingen videre til GID. GID vil s?, etter nok en vurdering, legge imaget-navnet til i imagelisten, med formen "image-navn:tag;nettskjema-nummer". Der "tag" er optional, siden vi som regel ?nsker "latest". Deretter m? endringen commites og pushes til git. Il?pet av en times tid skal s? imaget v?re tilgjengelig i v?rt registry. Om det senere kommer nyere versjoner av dette imaget p? DockerHub vil samme skript oppdatere imaget p? v?rt registry.
6 Sikkerhetsskanning av imager
I nyere versjon av Harbor er det innebygd sikkerhetsskann av imager. Man vil derfor f? en oversikt over sikkerhetshull, av forskjellig alvorlighetsgrad, for et gitt image. Hvert prosjekt er selv ansvarlige for ? f?lge opp sikkerhetskanningen av sine imager, og patche de sikkerhetshull. Mislighold av imager kan i verste fall medf?re at tjenesten som kj?rer disse imager blir sperret.
For ? kj?re docker p? en sikker og god m?te er et docker-registry en n?dvendighet. Konsekvensen av at docker-registry blir komprimitert vil v?re at alle milj?er som benytter den ogs? er komprimitert, det er derfor naturlig at vi legger oss p? en streng linje n?r det gjelder sikkerheten av docker-registry.
6.1 Skanning av kj?rende kontainere
For ? forhindre at gamle imager, med kjente sikkerhetshull, st?r ? kj?rer uten vedlikehold har vi, uavhengig av Harbor, laget en l?sning som genererer en oversikt over alle kj?rende kontainere p? alle UiO-driftede RedHat-servere. Denne oversiktet lages ut fra imaget kontaineren kj?rer fra, slik at vi enkelt kan se om hvilke versjoner de forskjellige milj?ene kj?rer. Ogs? her vil rapportene kunne avdekke eventuelt mislighold som i verste fall kan medf?re at tjenesten blir sperret.
7 Logge inn i Harbor
Harbor er alts? tilgjengelig p? https://harbor.uio.no.
7.1 Via web
En innlogging via https://harbor.uio.no gj?res med driftbrukere, man vil etter ? ha logget inn f? en oversikt over prosjektene man har tilgang til. Web-GUIet til harbor brukes hovedsaklig til ? f? en oversikt, unders?ke sikkerhetsskan-rapportene, slette imager.
7.2 Via API
APIet derimot vil hovedsaklig brukes av systembrukere for ? pushe imager man har bygd eller oppdatert, eller laste ned imager man allerede har bygget.
Innlogging gj?res med:
docker login -u <brukernavn> harbor.uio.no:443
Man blir s? spurt om passord.
8 Bruk av Harbor
Ansvaret for at et image holdes oppdatert og er sikkert ligger hos den gruppen som har bygd imaget. Det er derfor lurt ? automatisere byggeprosessen av imager s? mye som mulig. Kriteriene for at en byggeprosess skal starte er gjerne flere, men iallefall:
- Kildekoden man bygger fra har endret seg.
- Base-imaget man bygger p? har endret seg.
8.1 Bygging av image
Retningslinjene for bruk av Docker sier at bygging av image skal gj?res ved hjelp av Dockerfile. Det legger s?ledes ingen f?ringer p? hvilket verkt?y imaget blir bygget med s? lenge verkt?yet kj?rer p? en UiO maskin. Siden USIT har kompetanse p? Jenkins, anbefaler vi at selvsagt dette. Det er heller ikke tillatt ? bygge image ute i eksterne l?sninger utenfor UiO.
Syntaks for bygging av image fra en Dockerfile er som f?lger:
docker image build [OPTIONS] PATH | URL | -
Om man st?r i mappen der Dockerfile ligger holder det da med:
docker image build .
Imaget ligger n? lokalt p? serveren der imaget er bygget. Videre m? imaget tagges f?r det kan sendes til registry.
8.2 Tagg et image
N?r et image er bygget m? man gi imaget en eller flere tags f?r man kan "pushe" imaget til harbor. Det er viktig at en av taggene imaget f?r er unikt. Alts? det holder ikke ? gi imaget taggen "test", da "test" kan v?re en oppdatert versjon av imaget neste uke. Vi anbefaler derfor ? tagget imaget med git-commit-hasher som vil v?re unikt og reproduserbart.
P? denne m?ten gj?r vi det mulig ? gjenskape et milj? p? et senere tidspunkt for debuggig eller sikkerhetsanalyse.
Man kan s? i tillegg gi det samme imaget som har taggen "<commit-hash>" taggen "utvikling" og pushe begge opp til harbor. Om man da konfigurerer utviklingsmilj?et til ? benytte imager med taggen "utvikling" kan man raskt oppgradere applikasjonen sin, men beholde sporbarhet av endringer.
Fra kommandolinjen kan man tagge et image p? f?lgende m?te:
docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
Siden vi ikke skal pushe imaget til DockerHub m? vi ogs? spesifisere hvilket registry som imaget skal pushes til:
docker tag harbor.uio.no:443/<prosjekt>/<applikasjon>:<tag1> harbor.uio.no:443/<prosjekt>/<applikasjon>:<tag2>
Her f?r alts? imaget <prosjekt>/<applikasjon>:<tag1> en ny tagg, nemlig tag2. ?nsker man ? gi det samme imaget flere tags, kan man repetere prosessen med <tag3> istedet for <tag2>. Husk at begge taggene m? pushes i neste steg. Dette er noe man typisk gj?r ved bygging av nytt image. F?rst tagges imaget med "commit-hash" og s? "utvikling" eller "dev" eller "utv".
Om imaget man ?nsker ? tagge ikke er lastet opp til harbor.uio.no m? det gj?res f?rst:
docker tag <applikasjon>:<tag1> harbor.uio.no:443/<prosjekt>/<applikasjon>:<tag2>
8.3 Push et image
F?r man gj?re en "push" m? man v?re logget inn i harbor via APIet og ha skrivetilgang til <prosjekt>.
Deretter pusher man imaget med f.eks:
docker push harbor.uio.no:443/<prosjekt>/<applikasjon>:<tag2>
Imaget lastes n? opp og vil v?re tilgjengelig for nedlasting for alle brukere med lesetilgang til prosjektet i harbor. I de tilfeller der imaget har flere tags, m? man gj?re en push for hver tag.
8.4 Pull ned et image
Gitt at imaget man ?nsker ? hente ned er pushet opp til registry henter man ned nye imager med:
docker pull harbor.uio.no:443/<prosjekt>/<applikasjon>:<tag>
Dette forutsetter ogs? at man er logget inn via APIet og har lesetilgang til <prosjekt>.
8.5 Slette imager
Sletting av imager er kun tilgjengelig via GUI og krever admin-tilgang for <prosjekt>. Det er verdt ? merke seg at imaget ikke forsvinner fra servere som allerede har lastet det ned. Om et image har flere tags holder det ? slette et av de siden registry kun lagrer imaget en gang.
9 Fra utvikling til produkjon
Bruk av docker som applikasjonsplattform kan gi et tempol?ft i hvor ofte man deployer nye versjoner til produksjon. Tiden det tar ? b?de bygge et nytt image er gjerne bare noen sekunder eller minutter, og om dette gj?res automatisk av Jenkins kan man for se for seg at man ?nsker ? slipper sm? bugfikser flere ganger om dagen.
Vi vil etterhvert legge eksempler her p? hvordan man kan konfigurere en Jenkinsjobb til ? bygge Docker-image.