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.