81 total views,  3 views today

I denne artikkelen vil jeg skrive noe om begrepet autentisering. Dette har jeg undervist en del om, og erfarer at det er et tema som mange synes er vanskelig. Og det er litt omfattende, så vi skal diskutere to ulike aspekter ved begrepet:

• Tillit: Hvilke garantier har du når noen har autentisert seg overfor deg?
• Protokoller: Hvordan skal en autentiseringsoperasjon være utformet for at slike garantier kan gis?

(c) Anders Fongen, 2023

Hva betyr ordet?

“Autentisering” betyr å gjøre deg trygg på at du kjenner identiteten til en du samhandler med. La oss starte med en litt overfladisk beskrivelse av prosessen:

1. Du skal logge deg inn på Ebay.com, og skriver inn ditt brukernavn og passord.
2. Tjenermaskinen hos Ebay.com sjekker at det er dette passordet som er registrert med det brukernavnet, og godkjenner innloggingen. 
3. De påfølgende handlingene i Ebay legger til grunn at det er din person som utfører handlingene, og du kan gjøres ansvarlig for svindel og misbruk gjennom rettsapparatet.

Ebays formodning i punkt 3 er et uttrykk for tillit til at en del forutsetninger er oppfylt:

• At brukernavnet som benyttes faktisk er knyttet til din person
• At du har holdt passordet hemmelig og ikke fortalt det til noen
• At du ikke har skadevare på maskinen din som snapper opp passordet og misbruker Ebay-kontoen din
• At det ikke er praktisk mulig å modifisere eller gjenbruke meldingene som overføres på en slik måte at din konto kan misbrukes

Autentisering har også en annen type anvendelse enn pålogging til en nett-tjeneste: Nemlig å produsere et bevis for hvem som har skrevet et stykke tekst, en lydfil, et bilde o.l., altså alt som sendes som en melding og lagres som en fil. Da skal det være mulig å identifisere opphavet for dataene også lenge etter mottaket, og etter en tids lagring. For å få til en slik autentisering bruker vi noe av de samme teknikkene, men det oppstår også noen nye problemstillinger som vi ikke får plass til å diskutere i denne artikkelen.

Tillitskjede

Dette var en ganske lang liste med forutsetninger! Den viser at tilliten til en autentiseringsoperasjon beror på tilliten til et antall ledd i en tillitskjede (trust chain), og dersom ett av leddene svikter, mister man straks tilliten til sluttresltatet.

Skal vi snakke grundig om autentisering kommer vi altså ikke utenom denne tillitskjeden hvor leddene er både av teknologisk og administrativ art. Siden den bloggen du nå leser i er mest interessert i teknologi, vil vi kun omtale de administrative tiltakene i kort form. 

Hva skiller deg fra alle andre?

En kan autentisere seg overfor en motpart ved å demonstrere at man innehar en viss type informasjon som ingen andre har. På engelsk kalles dette proof of possession.

Det vanligste er å demonstrere kjennskapet til et passord, altså noe man vet. Man kan også demonstrere noe man har, f.eks. en mobiltelefon, eller noe man er, f.eks. et fingeravtrykk. Selvfølgelig kan dette kombineres, slik vi gjør hver dag i såkalt to-faktor innlogging: En må demonstrere et passord og bevise at man besitter en bestemt mobiltelefon  (egentlig et SIM-kort) ved å skrive inn en kode som sendes som tekstmelding til denne.

Med demonstrere mener vi ikke overføre! Vi vil ikke risikere at en inntrenger som avlytter en forbindelse skal få kjennskap til den aktuelle informasjonen. Vi vil også hindre en inntrenger å spille av en tidligere overført informasjon (kalt replay-angrep). Mer om dette siden.

Demonstrere betyr altså bevise at man innehar, men det må skje på en måte som hindrer avlytting, fabrikasjon (forfalskning) og avspilling. Disse tre begrepene skal vi vise eksempler på etter hvert.

Kopling mellom identifikator og entitet

Når jeg autentiserer meg over en motpart vil jeg oppgi en identifikator, f.eks. e-post adressen min, og leverer så proof of possession for å vise at jeg faktisk “eier” denne identifikatoren. Vi forutsetter altså at det alltid er en person som eier identifikatoren.

Altså: jeg (personen) kalles en entitet, og jeg kan representeres av en rekke identifikatorer. Dette kan være unike identifikatorer, slik som mitt personnummer eller min e-post adresse. En identifikator kan også være flertydig, som et personnavn ofte er. En unik identifikator kan settes sammen av flertydige identifikatorer, f.eks. navn og bostedsadresse.

Koplingen til en entitet er viktig fordi det er personen som må kunne holdes ansvarlig ved misbruk eller feil bruk som er knyttet til identifikatoren. Derfor er hva jeg er av interesse, fordi mitt fingeravtrykk eller andre biometriske data fra meg ikke kan stjeles (her gjelder det dog noen forbehold). Teknologiske løsninger for å kople identifikator med entitet blir det fortsatt forsket på, men for situasjonen i dag vil denne koplingen i hovedsak være basert på administrative tiltak.

Eksempler på autentiseringsprotokoller

La oss nå ta forutsetningene som nettopp er gjennomgått og konstruere noen autentiseringsprotokoller, alså regler for utveksling av meldinger gjennom kommunikasjonsnettet for å gjennomføre en autentiseringsoperasjon. De fleste av disse protokollene er egnet for diskusjonsformål, men er ubrukelige i praksis.

Protokollene blir vist på figurer som kalles interaksjonsdiagrammer. De vertikale linjene er tidsakser, og de vertikale linjene viser hvordan meldinger utveksles mellom partene Arne og Berit, representert ved firkantene på figurene. Svarte linjer indikerer meldinger som inngår i autentiseringsoperasjonen, røde linjer representerer påfølgende meldinger knyttet til selve applikasjonen.

a. Sende kun identifikator

I dette tilfellet sender Arne kun en identifikator, som blir uten videre godtatt av Berit. Arne beviser intet eierskap til identifikatoren (med f.eks. et passord) og kan sende hvilken som helst identifikator med samme resultat. Denne protokollen oppfyller ikke kravene vi listet opp om å demonstrere “proof of possession”, og er derfor ubrukelig!

b. Sender identifikator og passord

I dette tilfellet vil Arne demonstrere sitt kjennskap til et passord, som er knyttet til brukerkontoen og lagret i tjeneren. Problemet her at dette ikke skjer på en måte som er sikret mot avlytting, fabrikasjon og avspilling. En inntrenger som lytter på forbindelsen (en antagelse vi alltid må gjøre) vil i dette tilfellet kunne avlese passordet idet det blir overført, og siden bruke det for å logge seg inn på Arnes konto. Protokollen oppfyller ikke kravet til sikkerhet mot avlytting, og er derfor ubrukelig.

c. Sender identifikator og hashet passord

La meg først forklare hva en hash-funksjon er: Den lager et slags slags “fingeravtrykk” av en datafil eller en melding. Fingeravtrykket har en fast lengde uavhengig av størrelsen på meldingen. Om vi ønsker å sammenligne innholdet av to meldinger eller datafiler, kan vi nøye oss med å sammenligne deres hash-verdier. En viktig egenskap ved en hash-funksjon er at den ikke kan reverseres. Ut fra en hash-verdi er det ikke mulig å rekonstruere den opprinnelige meldingen. På en Linux-maskin kan hashalgoritmen sha1 demonstreres på denne måten:  

anders@penguin:~$ echo ‘asdasdasd’ | sha1sum
09a9202377d81198d409391ca54376d9c3eaadf2  –

anders@penguin:~$ echo ‘asdasdase’ | sha1sum
a7d61d3b95e2f3253d4e6f3f495d0bf98398c568  –

Vi ser her at disse to tegnstrengene har bare én bit forskjell (i siste bokstav, ‘d’ og ‘e’ adskilles med kun en bit) gir vidt forskjellige hash-verdier.  Med disse egenskapene er en hash-funksjon godt egnet for å overføre et passord.

Protokollen er vist på figuren nedenfor.

I dette tilfellete vil Arne sende sitt brukernavn og hash-verdien av sitt passord, kalkulert med f.eks. algoritmen sha1. Berit kjenner Arne’s passord og kan kalkulere hash-verdien og sammenligne med den mottatte verdien. Sjansen for at et annet passord har samme hashverdi er ufattelig liten. 

Med denne protokollen er det altså ikke mulig for en som avlytter forbindelsen mellom Arne og Berit å avlese Arnes passord. Men protokollen har en stor svakhet, den er utsatt for såkalt replay attack, som jeg her kaller for avspilling. En inntrenger kan lagre hva Arne sender og siden spille dette av i en ny forbindelse til Berit, og dermed utrettmessig få adgang til Arnes brukerkonto. Denne svakheten oppstår fordi alle autentiseringsoperasjoner fra Arne er likt utformet. Så neste versjon av protokollen vil sørge for at påfølgende autentiseringsmeldinger fra Arne får ulikt innhold.

d. Blander en nonce med passordet

På figuren over ser vi at Arnes første melding presenteres hans brukernavn, og Berit svarer med et slags tilfeldig tall, kalt nonce. En nonce (“number once”) er en tallverdi som aldri mer skal brukes, og som garanterer at to like noncer aldri vil deles ut. I praksis kan en nonce være et tilfeldig stort tall, som med svært liten sannsynlighet vil opptre igjen.

Arne kombinerer så sitt passord med nonce-verdien og kalkulerer hashverdien av resultatet, og sender den til Berit. Berit, på sin side, gjør den samme kalkylen (Berit må derfor kjenne passordet i klartekst) og sammenligner med det som Arne sender.

En slik protokoll oppfyller de kravene vi stilte opp tidligere i artikkelen, og lar Arne autentisere seg trygt over Berit. 

Vi ønsker i tillegg en løsning som binder autentiseringen til den påfølgende meldingsutvekslingen slik at det ikke er mulig for en inntrenger å “smette” inn eller endre meldinger etter at autentiseringsoperasjonen er fulllført. Vi kan løse dette med bruk av hash-funksjoner eller kryptering, men da må Arne og Berit være i stand til å utveksle en felles krypteringsnøkkel under autentiseringen som ikke kan avlyttes av en inntrenger. Det blir målet for den neste versjonen av autentiseringsprotokollen.

Litt om asymmetrisk kryptering

Vi tar et lite sidesprang nå for å forklare begrepet asymmetrisk kryptering. Dersom du allerede har kjennskap til dette feltet kan du hoppe over denne teksten.

Mens tradisjonell (symmetrisk) kryptering baserer seg på at både sender/kryptering og mottaker/dekryptering benytter samme krypteringsnøkkel, vil asymmetrisk kryptering bruke ulike nøkler for kryptering og dekryptering. Vi snakker derfor om et nøkkelpar for bruk i slike operasjoner, og det er da vanlig at en entitet (representert ved en identifikator) besitter et slikt par av nøkler, betegnet K⁺ (kalt offentlig nøkkel) og K^– (kalt privat nøkkel). De to nøklene er ulike, men ikke uavhengige. Den offentlige nøkkelen kan være kjent for alle, mens den private nøkkelen er kjent kun for eieren. Kryptering (vist om en funksjon E) og dekryptering (funksjonen D) bruker nøklene på følgende måte. P betegner data i klartekst, C betegner krypterte data:

Kryptering: C = E(K_A⁺, P)
Dekryptering: P = D(K_A^–,C)

Ut fra disse reglene fremgår det at alle kan lage kryptotekst med Arnes offentlige nøkkel, men kun Arne kan dekryptere disse dataene. Derfor kan alle som vil, kryptere data som bare Arne kan lese. Denne egenskapen skal utnyttes i neste versjon av autentiseringsprotokollen.

e. Demonstrerer besittelse av privat nøkkel

I denne versjonen vil Arne benytte sitt nøkkelpar for asymmetrisk kryptering for å autentisere seg. I tillegg ønsker vi at partene skal utveksle en krypteringsnøkkel for å beskytte den påfølgende informasjonsflyten mellom dem. Denne nøkkelen må selvfølgelig overføres på en måte som beskytter mot avlytting fra en inntrenger. 

Arne starter med å presentere sitt nøkkelsertifikat for Berit. Nøkkelsertifikatet er et digitalt dokument som inneholder Arnes identifikator og hans offentlige nøkkel. Når Berit mottar dette vet hun hvem som ber å bli autentisert, og dennes offentlige nøkkel. Berit velger nå en tilfeldig verdi som en midlertidig symmetrisk nøkkel kalt K_secret, som hun krypterer med Arnes offentlig nøkkel, og sender dette tilbake til Arne.

For at Arne nå skal kunne dekryptere denne meldingen må han besitte Arnes private nøkkel. Dermed får han bruke K_secret til å kryptere og dekryptere de påfølgende meldingene. Det at Arne klarer å delta i denne meldingsutvekslingen er dermed en proof of possession av hans private nøkkel, som bare han har kjennskap til.

Nå har vi klart å lage en fungerende autentiseringsprotokoll som også beskytter den meldingsutvekslingen som følger etter autentiseringsoperasjonen. Men det er fortsatt noe vi ønsker i en autentiseringsprotokoll og det er gjensidighet.

Med gjensidig (mutual) autentisering mener vi at begge parter autentiserer seg overfor motparten. Dette er en viktig egenskap fordi om Arne blir lurt til å snakke med en som utgir seg for å være Berit (noe ingen av de hittil viste autentiseringsprotokollene kan forhindre) kan Arne bli lurt og svindlet på mange slags måter i den påfølgende meldingsutvekslingen. 

f. Gjensidig autentisering

I denne versjonen av autentiseringsprotokollen bruker vi også prinsippet om asymmetrisk kryptering i likhet med den forrige versjonen, men her ser vi at nøkkelsertifikatene utveksles i begge retninger, og det utveksles to midlertidige nøkler, som brukes til å kryptere påfølgende meldinger i hver sin retning. Prinsippet er altså det samme som i versjon (e), og brukes i begge retninger.

Legg merke til at vanlig passordbasert autentisering ikke er praktisk ved gjensidig autentisering. Om Berit er en tjeneste som benyttes av mange, er det ikke fornuftig å la mange kunder som, i likhet med Arne, må kjenne Berits passord.

Merk også at denne autentiseringsalgoritmen kan utformes på flere forskjellige måter: En av dem er å benytte digital signatur, en annen vil være å bruke samme midlertidige nøkkel i begge retninger. Den foreslåtte metoden er bare bare én av flere mulige. 

“Denial of service” angrep

Forkortet DoS, på norsk kalt tjenestenektangrep, betegner et angrep som har som mål å hindre andres bruk av tjenesten. I protokollutgave (d) og (f) vil Berit motta en innledende forspørsel fra Arne, respondere på denne mens den venter på neste melding fra Arne. Dersom Arne er en ondsinnet part kan han la være og sende denne neste meldingen, og la Berit vente i det uendelige mens hun fortsatt vil måtte huske at en autentiseringsoperasjon med Arne er i gang. Dersom en angriper sender en million slike innledende meldinger, kan minnet til Berit fylles opp slik at ingen flere autentiseringsoperasjoner kan gjennomføres, og de lovlige brukerne av tjenesten ikke slipper til. Dette kan derfor utgjøre et tjenestenektangrep, og en som skriver koden for Berit må f.eks. sette tidsgrenser for hvor lenge hun vil vente på neste melding fra Arne, utover denne tidsgrensen kan autentiseringsoperasjonen avbrytes.

Oppsummering

I denne artikkelen har vi gått gjennom prinsippene for autentiseringsoperasjonene, og vist en del eksempler på autentiseringsprotokoller, både noen ubrukelige og noen som virker. 

De beste autentiseringsprotokollene som vi har vist, (d), (e) og (f), kan garantere den som ønsker å autentisere seg har demonstrert eierskapet av noe han vet. I dette tilfellet er det enten et passord eller en privat nøkkel. Det foreligger derimot ingen garanti at dette er den personen (entiteten) som representeres av identifikatoren. En slik garanti, kalt establishment of identity, er svært vanskelig å gi, selv med avanserte biometriske teknikker som en del av autentiseringsprotokollen. Dersom passordet eller den private nøkkelen lekkes til andre er det som regel mulig for dem å utgi seg for den personen passordet hører til.

Takeaway fra denne artikkelen

1. Autentisering er proof of possession av noe du vet, noe du har, eller noe du vet.
2. Overføres på en måte som er sikret mot avlytting, forfalskning eller avspilling.

 136 total views,  1 views today

Anders Fongen, september 2022

Dette er et blogginnlegg som skal diskutere nettverk av Docker-kontainere, hvordan de kan kommunisere gjennom beskyttede interne nett, og hvordan de kan opptre i svermer under styring av en sentral kontrollnode. Forutsetningen for å få godt ubytte av denne teksten er grunnleggende kjennskap til bygging og kjøring av vanlige Docker-komponenter (eng. images)

Vi kan enkelt tenke oss fornuftige anvendelser hvor en Docker-komponent har nytte av å påkalle tjenester fra en annen komponent. Dette er da typisk en komponent som ikke betjenes med en HTML-basert web -dialog, men som benytter maskin-til-maskin kommunikasjon (m2m). Slik kommunikasjon kan gjerne være basert på HTTP-protokoll og benytte programmeringsbiblioteker for dette, men vil ha innholdet kodet med XML eller JSON. Slike komponenter forbinder vi med begrepet Service Oriented Architecture (SOA). Jeg kommer ikke til å komme inn på slik programmering her, men det finnes mengder av læremidler der ute basert på ditt favoritt programmeringsspråk.

Beskyttet nettverk internt i Docker

Når en komponent ønsker å kalle en annen, er det selvfølgelig mulig å utplassere den kalte komponenten slik at den kan kalles fra “utsiden” (evt. hele Internet) og bruke denne utvendige IP-adressen som servicepunkt. Det er lett å tenke seg hvorfor dette ofte ikke er ønskelig: Uvedkommende kan fritt utnytte og sabotere tjenesten med mindre man lager mekanismer for adgangskontroll, noe som strengt tatt ikke burde vært nødvendig.

Docker tilbyr derimot “interne” nettverk som kun er synlig for Docker-kontainere på den samme maskinen og som er koplet til det interne nettverket. I det man skaper et slikt nettverk:
$ docker network create my-internal-network
$ docker network ls
$ docker network inspect my-internal-network

vil det også bli tildelt en subnett-adresse, og forsynes med tjenester for tildeling av adresser fra subnettet (lik DHCP) og tjenester for å finne IP-adresser til de tilkoplede kontainerne (lik DNS). For siden å kople en kontainer til nettverket kan vi velge to metoder:

1. Kople til nettverket i det kontaineren skapes, f.eks slik:
   $ docker run -p 80:80 --name mycontainer --net my-internal-network image-name
   
   Med denne metoden vil kontaineren mycontainer være knyttet til kun my-internal-network. Om kontaineren skal være knyttet til flere nettverk, bruk metode nr.2:
   
2. Lage kontaineren, kople til nettverket og starte programmet, i tre steg (eksempelvis)
   $ docker create -p 80:80 -name mycontainer image-name
$ docker network connect my-internal-network mycontainer
$ docker network connect my-second-internal-network mycontainer
$ docker network disconnect bridge mycontainer
$ docker start mycontainer
   Denne listen av kommandoen viser bruken av create, som oppretter en kontainer uten å starte den, network connect som kopler kontaineren til interne nettverk, og disconnect, som kopler fra nettverk. Deretter starter kjøringen av programmet i kontaineren med $docker run.

Det forholder seg nemlig slik at en kontainer som standardinnstilling koples til et nettverk kalt bridge. Alle andre kontainere vil også ha forbindelse til denne, noe som i mange tilfeller ikke er ønskelig. Metode nr.1 vil erstatte bridge-forbindelsen med en forbindelse til my-internal-network. Metode nr.2 vil legge nye forbindelser til eksisterende.

Eksempel 1 – BusyBox

Som eksempel på viste metode nr.2 kan komponenten BusyBox brukes. Den gir et lite Linux-kjøremiljø som vi kan skrive kommandoer til.

Først lister vi opp eksisterende nettverk og skaper to nye:

Vi er interessert i å vite subnet-adressene til disse to nye nettene:

Vi skaper en kontainer med BusyBox-komponenten og knytter den til de to nye nettverkene, i tillegg til bridge:

Nå starter vi kontaineren bb med BusyBox inni, og skriver kommandoen ip a for å se nettverkskonfigurasjonen på komponenten:

Fra denne kommandoen ser vi de tre ethernet-adaptrene eth0, eth1 og eth2 med subnettadresser som tilsvarer nettverkene bridge, my-net-1 og my-net-2. Som nevnt tidligere ville vi trolig koplet fra bridge for å unngå påvirkning fra uvedkommende komponenter.

Eksempel 2 – Trafikk mellom to Docker-komponenter

Det første eksemplet viste kun konfigurasjon av nettverksforbindelser, ikke hvordan vi kan bruke dem. Derfor vil vi nå sette opp komponenten first slik at vi kan kalle den fra busybox med linux-kommandoen wget og vise html-innholdet som first sender. Komponenten first er beskrevet i et tidligere blogginnlegg.

Her brukes kommandoene som er vist som metode nr.1 ovenfor og vi starter henholdsvis first og busybox med forbindelser til my-net-3. I busybox bruker vi kommandoene slik:

1. ip a for å se at vi har fått et nettverksadapter med en adresse fra subnettet til my-net-3
2. ping first for å vise at det foreligger en navnetjeneste som kopler navnet first (navnet på kontaineren) til ip-adressen 172.27.0.2, og at det foreligger en virkelig forbindelse dit.
3. wget first:8080 for å sende et http-forespørsel til 172.27.0.2, port 8080 og lagre svaret på filen index.html.
4. more index.html for å vise innholdet av denne filen på konsollet.

Vi har altså med dette eksemplet demonstrert at to komponenter kan ha en nettverksforbindelse som er skjermet fra andre komponenter. Det som er verd å huske er:

• Interne nettverk får automatisk en subnett-adresse.
• Containere som kopler seg til et internt nettverk får tildelt IP-adresse automatisk.
• Interne nettverk (unntatt bridge) har en navnetjeneste som returnerer IP-adressen til navngitte containere. Derfor er det lurt å gi containere et navn med --name parameteren.

Av en eller annen grunn er det ingen navntjeneste i nettverket bridge, slik at ping first ikke vil fungere dersom komponentene ønsket å kommunisere over det nettverket.

Docker-compose

En applikasjon vil gjerne bestå av flere Docker-containere som samarbeider og må konfigureres og startes på en kontrollert måte. Enkeltkommandoer som vist i eksemplene ovenfor kan kanskje settes sammen i en kommandofil (.bat, .sh) og kjøres samlet. Dette forutsetter at du har konsoll-adgang til maskinen som skal kjøre applikasjonen, og at ulike maskiner kan forstå denne kommandofilen. Dette er forutsetninger som ikke kan garanteres. Docker-compose vil øke portabiliteten av applikasjoner og forenkle konfigurasjonen, siden alt foregår i én fil.

Derfor kommer Docker-compose inn som et verktøy hvor detaljer vedrørende konfigurasjon og kjøring for alle komponentene i applikasjon kan uttrykkes i én fil. Denne filen har en såkalt YAML-syntaks, som skal vises i eksemplet som følger.

Filen skal hete docker-compose.yml. Som eksempel på utforming skal vi bruke konfigurasjonen i eksempel nr.2 ovenfor. Innholdet i filen er som vist under:

Syntaksen og mulige informasjonselementer i denne YAML-filer (uttales “jammel”) er ganske omfattende, og en oversikt finner du her. Derfor velger jeg heller å demonstrere ett bestemt kjent tilfelle med en typisk struktur: nettverksforbindelse, volumer, eksponerte porter. Elementene under disse to vil være tilsvarende de parametrene vi tidligere ga på kommandolinjen. For first, legg merke til at build: nå må ha et stinavn til der hvor kildefilene til first ligger.

Syntaksen i den viste docker-compose.yml skal forstås som et hierarki der innrykk av teksten viser en “tilhørighet” til linjen ovenfor med kortere innrykk. Her har vi altså tre hovedkategorier: services, volumes, networks. Før en kontainer kan knyttes til et volum eller nettverk må disse først deklareres på denne måten. Under networks finner vi hvilket nett som skal brukes i applikasjonen og hva dette skal hete.

Under services finner vi de to vi har arbeidet med så langt, bb og firsts. For bb kommer det to linjer knyttet til stdin_open og tty, som har å gjøre med at vi ønsker konsolltilgang til denne kontaineren, noe som i mange tilfeller ikke vil være aktuelt. Derfor vil denne viste filen ha de fleste av de egenskapene du i praksis vil trenge.

La oss nå gi denne filen til Docker-compose og se hva som kommer ut av det. Arbeidskatalogen (current directory) må være den som inneholder docker-compose.yml . Oppstart skjer med kommandoen $ docker-compose up:

Nå er både bb og first started i hver sine kontainere, men vi får ingen konsolltilgang til å skrive kommandoer i. Til forskjell fra eksempel nr.2 må vi skrive dette i tilegg:
$ docker exec -it bb sh
Denne kommandoen utfører kommandoen sh i kontaineren som heter bb. Parameteren -it gjør at sh også kommuniserer med konsollet, så vi får en interaktivt Linux-konsoll. Nå kan vi teste at det er kommunikasjon mellom bb og first:

Dette må dog skrives i et annet CMD-vindu, fordi vinduet der vi startet docker-compose er opptatt. Der kan vi derimot lukke applikasjonen og stanse kontainerne ved å trykke ctrl-C noen ganger:

Kommandoen $ docker ps -a viser en liste over kontainerne og at disse er stoppet. Vi kan nå slette én og en kontainer med kommandoen $ docker rm bb first, men en enklere måte er $ docker container prune, som sletter alle inaktive kontainere under ett. Inaktive kontainere kan okkupere en del ressurser i systemet, og det er sunt å rydde regelmessig.

Docker swarms

I et storskala informasjonssystem vil en web-tjeneste kjøre på mange maskiner i parallell. Da oppnår man at maskinene kan fordele kundetrafikken mellom seg for å oppnå høyere total ytelse (kalt lastfordeling), og at noen av maskinene kan falle ut av drift uten at systemet som sådan blir utilgjengelig (kalt fail-over). Denne formen for ressursorganisering krever en sjef (manager), som fordeler forespørsler mellom arbeiderne (workers) og som holder oversikt ettersom maskiner går inn eller ut av drift.

Docker-arkitekturen egner seg godt til å inngå i en slik storskala arkitektur, siden tilstandsløse komponenter kan dupliseres på flere maskiner og utføre nøyaktig den samme tjenesten. Kunder vil se ett eneste servicepunkt (IP-adresse og port) og ikke merke noe til at tjenesten er fordelt på mange maskiner. La oss derfor se på hvordan Docker-komponenter kan organiseres som en Docker swarm:

Bruk helst Linux-maskiner

Selv om kommandoene for Docker-svermer også finnes på Windows-versjonen av Docker-systemet, er det en del egenskaper som simpelthen ikke virker som forventet. Det er derfor å anbefale at et eksperiment med Docker-svermer kun benytter Linux-maskiner. Husk også at Docker-komponenter ikke er arkitekturnøytrale, de kan ikke kjøre både på X86- og ARM-maskintyper. Ikke blande f.eks. Raspberry Pi (ARM) med ordinære PCer (X86) i en Docker-sverm.

Alt foregår fra sjefen

For å bygge opp en sverm må maskinene kunne nå hverandre gjennom et IP-nettverk, det er ikke tilstrekkelig at sjefen kan nå alle arbeiderne, arbeiderne må også kunne kommunisere med hverandre. For først å bygge opp en sverm gjør vi følgende:

1. Bestem hvilke maskiner som skal delta, skriv ned deres IP-adresser og lag et kart som viser hvem som er sjef og hvem som er arbeidere. Fra konsollet til sjefen, logg inn (med ssh) på alle arbeiderne i separate konsollvinduer. Alle kommandoer som vises som eksempler må kjøres i sudo-modus (skriv sudo bash for komme dit).
2. På alle maskinene i svermen, sørg nå for at alle kontainere er stanset ($ docker stop ..., $ docker rm ...) og kontroller resultatet med $ docker ps -a.
3. På sjefens maskin, sjekk om det allerede er en sverm med $ docker node ls. Dersom det finnes en, fjerne dem med kommandoen $ docker swarm leave --force.
4. På sjefens maskin, opprett en sverm med kommandoen $ docker swarm init. Reponsen kan se omtrent slik ut:
   Swarm initialized: current node (icv8b9vnemxfmym4lb1gbto7f) is now a manager
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-0ezzbg9iw2glu6d7xd6c2shjvhadr7zlemwuf4l9besxl2iogl-a1yngnqehgyub0phopuslysly 192.168.2.116:2377
5. Ta en kopi av den uthevede teksten, og lim den inn i konsollvinduet til alle arbeiderne slik at kommandoen utføres der. De vil nå kople seg til sjefen (til ip-adressen som er vist i kommandoen) og slutte seg til svermen. Nå vil de etterhvert få opprettet kontainere for applikasjonstjenester og motta klientforespørsler.
6. Fra sjefens konsoll skriv $docker node ls for å kontrollere at alle arbeiderne er kommet inn i svermen.

Utplassering av en tjeneste i svermen

Nå kan sjefen plassere en tjenesten inn i svermen. Dette betyr, som tidligere nevnt, at en applikasjon blir plassert ut på én eller flere av arbeiderne (inkludert sjefen), og en forespørsel fra en klient blir betjent av én av dem.

Hvilken IP-adresse leder inn til den utplassert tjenesten? Svaret er at alle IP-adressene i svermen (altså endepunktet til alle arbeiderne og sjefen) gir adgang til tjenesten, også de arbeiderne som ikke betjener selve tjenesten. Det eksisterer et eget “overlay” nettverk mellom maskinene som fremforhandler fordelingen av arbeidsoppgaver og som videresender forespørsler fra klienter til en kandidat-arbeider.

Kommandoen skal skrives på sjefens konsoll. Sånn kan den se ut:

$ docker service create --name first --replicas 3 --publish 8080:8080 andfon7a/first

Den eneste nye parameteren siden de tidligere eksperimentene er --replicas som angir det maksimale antall arbeidere (inkl. sjefen) som skal laste denne applikasjonen. Legg også merke til at Docker-komponenten ikke må ligge på sjefens egen maskin, den kan hentes fra Docker-hub om nødvendig (og den må da evt. plasseres der på forhånd med $ docker push andfon7a/first).

Med kommandoen $ netstat -ant på alle maskinene i svermen kan man nå konstatere at port 8080 er “åpen”. Med en web-leser kan man kontake én av maskinenes IP-adresse på port 8080 og konstatere at tjenesten utføres korrekt.

For å inspisere tjenesten bruk kommandoen $ docker service inspect --pretty first. For å fjerne den skrives $ docker service rm first.

Opp- og nedskalering: Det opplagt nyttige i svermen er muligheten for å endre kapasiteten ved å øke eller redusere antall maskiner som deltar i en tjeneste. Det gjøres som følger (i dette eksemplet reduseres antallet fra 3 til 2):

$ docker service scale first=2

Konklusjon

Målet med dette blogginnlegget var å gi en kortfattet, men ukomplett, innføring i hvordan man setter opp nettverk og svermer av Docker-komponenter. Det fulle omfanget av muligheter og detaljer er mye større, men er blitt utelatt fordi det er lagt vekt på å vise konkret hvor enkelt det er å sette opp en grunnleggende tjeneste.

Jeg anbefaler først leseren å gjennomføre disse eksemplene på eget utstyr og så gjøre nødvendige endringer etter egen interesse: F.eks. hvordan en sverm kan operere med permanent lagring gjennom en filtjener eller en SQL-database. Slike komponenter er ikke enkle å replikere i en sverm og vil naturlig ligge i egne tjenester, gjerne i frittstående Docker-kontainere med muligheter for å lagre data i volumes.

 370 total views,  6 views today

Anders Fongen, september 2022

Å konstruere Docker-komponenter og utplassere (eng. deploy) dem i en lokal kontainer på egen maskin er en ganske overkommelig oppgave. Mer omstendelig er det å sette slike komponenter i drift i en sky. De store skytjenestene (f.eks. Amazon AWS, Google Cloud og Microsoft Azure) er svært store og komplekse installasjoner som skal kunne betjene kunder med helt ulike behov. De tilbyr alle en web-tjeneste (portal) som lar kunden laste opp egenutviklet programvare og konfigurere samspillet med de tjenestene som skyen tilbyr (f.eks. sikkerhet, backup, navnekataloger, fillagring og SQL-databaser). For alle disse skyene blir denne portalen svært omfattende og omstendelig å bruke. Kvaliteten på dokumentasjonen er dessuten svært varierende.

Jeg har tatt for meg utvikling, utplassering, feilsøking og drift av Docker-komponenter med påfølgende utplassering i Microsoft Azure. Etter vellykket utplassering er tjenesten tilgjengelig på Internet. Dette blogginnlegget vil vise hvordan det kan skje.

Hvorfor er skyen en god idé?

Visst er det mulig å sette opp en webtjener på ditt eget hjemmenett, bestille fast IP-adresse hos Internet-leverandøren, sette opp port forwarding på hjemmeruteren, og gi hjemmeadressen et DNS-navn. Denne prosessen har jeg forøvrig beskrevet i et eget blogginnlegg.

Med et slik løsning må du selv ta hånd om sikkerhet, backup, reserveløsninger ved systembrudd, brukertillatelser, og fremfor alt skalering. En vellykket tjeneste på Internet kan oppnå en svært rask vekst i kundemengden, og dersom du ikke klarer å opprettholde en akseptabel responstid under slike forhold har du mislykkes.

Disse kravene kan skyen innfri, fordi de besitter store datasentraler med høy nettverkskapasitet, og de kan raskt øke kapasiteten på tjenesten din, de kan endog gjøre det automatisk. Personellet i datasentralene er eksperter på skalering, sikkerhet, overvåking og etterforskning, og de har ingen annen jobb enn å passe på at tjenestene leverer stabilt og raskt. Du har andre oppgaver og vil ikke klare å gjøre denne jobben like godt.

Docker

Programvare som skal kjøres som en skytjeneste må skrives etter bestemte regler, og utplasseringen trenger noen opplysninger som må fremskaffes av kunden. Docker er programvare for å lage og kjøre skytjenester. Jeg skal ikke forklare Docker grundig her, fordi det finnes mye informasjon om nettopp dette på nettet:

• Docker Docs (her finnes også nødvendig programvare for nedlasting)
• Docker Curriculum

Det er nødvendig å gå gjennom noen eksempler på bygging og kjøring av Docker-komponenter på lokal maskin: Når Docker-komponenter kjøres på lokal maskin, f.eks. BusyBox, kan de kommunisere med brukeren gjennom konsollet, dvs. skjermen som brukes for å bygge og starte komponenter. Dette er ikke mulig på Azure, hvor komponenten må kommunisere med omverdenen gjennom nettverket (Internet).

Nettverkstrafikk kan omfatte protokoller som ssh, http, mqtt og det meste annet, men komponenten må selv besørge selve protokollen, Azure besørger bare UDP- og TCP porter, samt en brannvegg for å beskytte mot angrep via nettverket. Vi skal demonstrere bruk av Azure med web-komponenter som benytter http-protokoll.

Installasjon av programvare

For å kommunisere med Azure trengs programvaren Docker Desktop, installert på Windows eller Mac (bruk lenken ovenfor). I CMD-konsollet (Windows) kan man nå skrive $ docker for å utføre diverse kommandoer.

I den påfølgende tekst vil jeg bruke “$”-symbolet for å vise en kommando slik den skal skrives inn i CMD-konsollet. Dollartegnet skal altså ikke skrives inn.

For å utplassere Docker-komponenter på Azure trenger du følgende brukerkontoer:

1. Hos hub.docker.com. Her plasserer du dine komponenter slik at andre kan laste dem ned til seg og bruke dem. Kontoen er gratis.
2. Hos portal.azure.com. Her foregår selve kontrollen av Azur-aktivitetene. Duu må registrere et betalingskort, men du får også en romslig kvote gratis som du kan eksperimentere med.

Eksperimentprogrammer

To små Python-programmer blir brukt i denne demonstrasjonen: De ene er et enkelt tilstandsløst web-program som adderer to tall og viser resultatet, det andre web-programmet benytter en tekstfil som lagres på et permanent lager. Skillet mellom disse to programmene er hvordan de bruker permanent lager. Programmene ser slik ut:

Summere to tall (tilstandsløst web-program)

first.py:
import web
urls = ('/','index')

class index:
   def GET(self):
      f = open("first.html","r")
      return f.read()
   def POST(self):
      i = web.input()
      if i.a.isnumeric() and i.b.isnumeric():
         return "Svaret er %d" % (int(i.a)+int(i.b))
      else:
         return "Kun numerisk inndata er lovlig"

if __name__ == '__main__':
   app = web.application(urls,globals())
   app.run()

first.html:
<html><body>
  <h1>Addere to heltall</h1>
  <form method='POST'>
     <input name='a', size='4'>
     <input name='b', size='4'>
     <input type='submit' value='finn sum'>
   </form>
</body></html>

Dockerfile:
FROM python:3.8
WORKDIR /usr/src/app
COPY . .
RUN pip3 install web.py
EXPOSE 8080
CMD ["python","./first.py"]

Dette webprogrammet kan startes direkte fra kommandolinjen og tilby en enkel tilstandsløs tjeneste. Vi kan når som helst restarte tjenesten uten å forstyrre klientene. Vi kan lage en Docker-komponent og kjøre den lokalt på vår egen maskin med disse kommandoene (de tre filene må ligge på samme katalog, og katalogen må være arbeidskatalog (current directory):

$ docker build -t first .
$ docker run --name container1 -d -p 8080:8080 first

Nå er denne webtjenesten tilgjengelig på http://localhost:8080/. For å stoppe og fjerne tjenesten (f.eks. før utplassering av en ny programversjon) kan disse kommandoene skrives:

$ docker ps -a
$ docker stop container1
$ docker rm container1

Dele en liten datafil (tilstandsfylt web-program)

third.py:
import web, os

urls = ('/','index')
os.environ['PORT'] = '80'
app = web.application(urls, locals())
filename = "message.txt"
class index:
   def GET(self):
      if not os.path.isfile(filename):
         f = open(filename,"w")
         f.close()
         message = "Ingen melding"
      else:
         f = open(filename,"r")
         message = f.read()
      resp ="<html><body><h2>Din siste melding var: %s"%(message)
      resp += "<p>Skriv inn melding:<form method='POST'><input name='m' size='20'>"
      resp += "<input type='submit' value='Lagre melding'></form></body></html>"
      return resp
   def POST(self):
      i = web.input()
      f = open(filename,"w")
      f.write(i.m)
      f.close()
      raise web.seeother('/')

if __name__ == '__main__':
   app.run()

Dockerfile:
FROM python:3.8
WORKDIR /usr/src/app
COPY . .
RUN pip3 install web.py
EXPOSE 80
CMD ["python","./third.py"]

Dette web-programmet vil ta imot en tekstlinje og lagre den på en fil, som siden kan hentes frem av denne eller andre klienter. En form for datadeling altså. Filen som lagrer tekstlinjen bør bevares også når programmet stopper og starter igjen. Dersom vi kjører third.py som et vanlig Python-program vil filen ligge på vertsmaskinens filsystem, og vil dermed bevares slik vi ønsker.

Dersom vi lager en Docker-komponent som med forrige eksempel, vil også denne tekstlinjen bevares og utveksles mens Docker-komponenten kjører. Dersom Docker-kontaineren stoppes og startes igjen:

$ docker stop container1
$ docker start container1

(gitt at kontaineren er gitt navnet container1 ved docker run – kommandoen), da vil fortsatt tekstlinjen bevares slik vi ønsker. Dersom vi derimot fjerner kontaineren og lager en ny:

$ docker stop container1
$ docker rm container1
$ docker run --name container1 -d -p 80:80 third

Da har tekstlinjen fått det innholdet den hadde da Docker-komponenten ble laget (evt. tom), og endringer etter det tidspunktet er gått tapt. Altså, ikke slik vi ønsker at webtjenesten vår skal fungere.

Docker-komponenter med volumes

For å kunne bevare data også når docker-kontaineren slettes og skapes på nytt, må dataene lagres utenfor kontaineren, i vertsmaskinens filsystem. Dette er mulig å få til gjennom å montere en del av vertsmaskinens filsystem inne i kontainerens. Vi skal først endre én programsetning i third.py:

filename = "/app/message.txt"

og bygger web-tjenesten på lignende måte:

$ docker build -t third .
$ docker run --name container3 -v textdata:/app -d -p 80:80 third

Da oppnår vi nemlig det vi ønsker, nemlig at innholdet på området textdata i vertskapets filområde (i et nærmere bestemt filområde inne i Docker-installasjonen) vises under katalogen /app inne i kontaineren, og data som lagres under /app blir bevart selv når kontaineren slettes og gjenskapes. Dette kan kontrolleres ganske enkelt i et eksperiment.

Merk at dette permanente lageret kan lagre alle slags objekter, ikke bare tekstfiler: Bilder, lyd og selvfølgelig en databasefil fra f.eks. SQLite.

Litt om tilstander i Azure/Docker

Azure, i likhet med andre skyleverandører, lar Docker-komponenter kjøre i omgivelser som støtter stor skala, høy sikkerhet og dynamisk konfigurasjon. Det vil si at web-tjenesten som kjører kan gis et elastisk ressurstilbud ettersom pågangen øker og minker. Slik automatisk skalering skjer gjennom at Docker-komponenter kjører samtidig på mange maskiner i parallell (kalt flere instanser) og fordeler forespørselene mellom seg, og at antallet samtidige maskiner øker og minsker dynamisk.

Med datalagring inne i komponenten, slik vi har demonstrert med third.py, vil ikke en slik skalering kunne finne sted, fordi alle instansene vil ha ulikt datainnhold siden de betjener ulike forespørsler. Nei, skalering krever at Docker-komponenten benytter en separat lagringstjeneste som behandler skrivbare data (som filen message.txt i third.py ovenfor). Kun lesbare data kan fortsatt legges inne i Docker-komponenten dersom mengden ikke er for stor.

Dette skillet mellom brukerbetjening, forretningslogikk og datalager er en populær og velprøvd konstruksjonsteknikk for store informasjonssystemer. Trafikken mot datalageret (kalt back-end) er ofte lavere enn mot front-end (web-tjenesten) og datalageret kan skaleres med andre teknikker enn en front-end. Derfor ser vi at dette skillet mellom utføring og lagring i adskilte tjenester går igjen hos alle skyleverandører.

Utplassering av third.py i Azure

Vi skal hoppe over utplassering av first.py i Azure fordi det skjer på samme måten som med lokal Docker-plattform med noen små endringer, som vil fremgå av forklaringen som følger. Jeg skal gå gjennom utplassering av third.py i Azure, etter at den ene programsetningen er endret (filename = "/app/message.txt). Trinn for trinn er prosessen denne:

1. Bygge en lokal Docker-komponent. Navnet på komponenten må prefikses med brukernavnet i Docker-hub, som i mitt tilfelle er andfon7a:
   $ docker build -t andfon7a/third .
2. Plassere komponenten i Docker-hub. Det er nemlig herfra at Azure skal hente den senere
   $ docker login (Her kreves brukernavn og passord til brukerkontoen din)
   $ docker push andfon7a/third
$ docker logout
3. Logge inn i Azure og opprette filområdet
   $ docker login azure (Får du feilmelding “Azure lookup failure”, har du feil
   versjon av Docker installert. Bruk nyeste versjon av Docker desktop)
   $ docker context create aci mycontext (velg “create new resource group”)
$ docker context use mycontext
$ docker volume create mydata --storage-account andfon7astorage
4. Lag en kontainer og start komponenten i den. Den lastes inn fra Docker-hub
   $ docker run -p 80:80 --name third --domainname andfon7a -d -v andfon7astorage/mydata:/app andfon7a/third
5. Sjekk at kontaineren kjører og hvilket DNS-navn den har fått.
   $ docker ps -a
   – Sjekk nå med en web-leser at du får tak i tjenesten med dette DNS-navnet

Microsofts egen infoside om denne prosessen finner du her. Docker sin tilsvarende veiledning finnes her.

For å stoppe/starte/fjerne kontaineren bruker du kommandoene:
$ docker stop third
$ docker start third
$ docker rm third

Starting av en kontainer kan ta lengre tid enn kun kommandoen i konsollet. Bruk $docker ps -a for å se status i oppstartsarbeidet.

Om DNS-registreringen: For bruk av --domainname parameteren gjelder det at DNS-navnet blir registrert på den tildelte IP-adressen med en TTL-verdi på 300 sekunder. Dersom du under f.eks. eksperimentarbeid statid starter containeren på nytt kan du komme i situasjonen hvor DNS-tjenesten fortsatt en stund returnerer den forrige IP-adressen. Om du utelater --domainname parameteren vil $docker ps vise deg IP-adressen i den samme kolonnen , som alltid er riktig.

Huskn

Når du vil igjen jobbe lokalt eller mot Docker-hub:
$ docker logout azure
$ docker context use default

Docker-tjenester fra Amazon AWS og Google Cloud

Amazon AWS og Google Cloud er to konkurrerende skytjenester som i det store bildet har mye til felles. Begge disse kan enkelt støtte tilstandsløse Docker-komponenter, enklest gjennom egne kontrollprogrammer (à la docker) som installeres i Windows-konsollet (cmd).

• Google Cloud betjenes av programmet Gcloud som installeres på din lokale maskin. Opplastingen skjer direkte fra lokal maskin med commandoen gcloud run deploy, og nødvendige tilleggsopplysninger legges inn i den påfølgende dialogen.
• For Amazon AWS skjer utplasseringen ved hjelp av en tilleggsfil som inneholder de nødvendige ekstraopplysningene (som ikke ligger i Dockerfile). For en veiledning for dette, sjekk avsnittet “Docker on AWS” på denne websiden.

Ingen av disse to skytjenestene støtter derimot Volumer, slik vi har vist er mulig i Azure. Derimot har begge database-tjenester som kan brukes av Docker-komponenter for lagring. Dette dekker noe av behovet for permanent lagring, men krever også at programvaren i større grad er tilpasset for dette og blir derfor mindre portabel enn hva som er ønskelig. Databasetjenester er dessuten krevende å konfigurere, sammenlignet med et filsystem.