Forfatter: Marieke

Læsetid: 7 minutter

Denne artikel er en dansk genudgivelse af Docker101 -> 01-intro-yourfirstimage.

Lad os lave et simpelt Docker-billede.

Vi laver en Dockerfil til at definere vores billede. Som et basisbillede bruger vi python:3.11.0-alpine3.15.

Alpine er et letvægts-Linux-distribution, og vi vil lave en simpel python applikation for at lære om Docker-billeder og containere.

Du kan finde forskellige instruktioner på https://docs.docker.com/engine/reference/builder/ for at se detaljer og udforske flere muligheder.

Lad os bygge billedet og se resultatet af byggeprocessen:

Hver instruktionslinje i Dockerfilen tilføjer et ‘lag’ i filsystemet på det færdige billede. Resultatet af ‘Hello, DefaultGreeter’ viser, hvordan udførelsen af ‘echo’-kommandoen er en del af byggefasen. Det vil ikke have effekt på det færdige billede, eftersom det ikke tilføjer/fjerner noget i lagene.

Kør billedet

Lad os prøve at køre billedet:

Nu kører containeren. Du kan se alle dine kørende containere:

Dockermotoren definerer et Docker-netværk. Hver container får en IP-adresse i dette netværk.

Vi kan ikke nå slutpunktet for den kørende container fra vores værtsmaskine uden at definere en portmapping.

Lad os køre med en portmapping:

Læg mærke til, at vi nu har en mapping over port 5000 på værtsmaskinen til port 5000 på den kørende docker container.
Vi kan nu nå vores applikation fra vores værtsmaskine.

Vi kan levere konfiguration ved kørsel ved at bruge miljøvariabler:

Bemærk hvordan greeter-navnet er ændret med vores nye definition af miljøvariablen GREETER. Hvis vi prøver at få adgang til fødselsdags-URL’en, vil applikationen give os en fejl.

Vi kan også levere konfiguration ved kørsel ved at bruge volumen-mounts (montere filer i filsystemet på den kørende container):

Vores Python-applikation tillader konfiguration af forskellige hilsner ved brug af volumen-mounts.

Den er faktisk også sårbar over for et alvorligt problem – kan du se hvordan?

Hint: URL-kod ‘hello; echo Shell Injections are nasty; cat /data/hello’

Hvis du vil læse mere som dette, kan der findes flere tekster på https://github.com/KvalitetsIT.

Tænk et øjeblik over dit Kubernetes cluster. Forestil dig, at en ubuden gæst finder vej ind. Ved du præcis, hvad de kan tilgå? Eller endnu værre, hvis de har sneget sig ind i en af dine containere, hvad er så risikoen? Denne bekymring er ikke kun teoretisk; virkeligheden viser, at trusler mod vores digitale “ridderborge” vokser i takt med, at flere virksomheder flytter deres operationer online.

Læsetid: 7 minutter

Forskning afslører en voksende tendens: Flere virksomheder ser behovet for zero trust. Alligevel står mange over for betydelige udfordringer i implementeringen – næsten halvdelen af alle virksomheder ser det som en stor hurdle. Traditionelt har en solid ydre firewall været et tilstrækkeligt forsvar. En enkelt mur, en nøgle, en barriere – det var alt, vi troede, der skulle til for at holde fjenden ude. Men tiderne ændrer sig, og denne strategi holder ikke vand i længden. Vi hører oftere om virksomheder, der mister data eller bliver ramt af ransomware, fordi de indre forsvarslinjer simpelthen er for svage.

Den digitale borg

Analogien med en gammeldags ridderborg er ganske passende. Forestil dig en borg med en enkelt bro over voldgraven. Med soldater til at inspicere enhver, der krydser broen, føler man sig sikker – indtil en fjende finder vej ind. Pludselig er intet sikkert; fjenden kan frit bevæge sig rundt og plyndre alt fra små tyvekoster til kongerigets kronjuveler.
Det er her, zero trust-strategien kommer ind i billedet, en moderne tilgang, der beskytter din digitale borg langt mere effektivt. Med zero trust antager vi, at fjenden allerede kan være inden for murene. I stedet for at fokusere al sikkerhed ved porten, sikrer zero trust, at hver eneste bevægelse inden for borgen kræver ny godkendelse – ingen får lov til at bevæge sig frit uden den rette tilladelse.

Så hvad er zero trust egentlig?

Zero trust går ud på, at vi antager, at “nogen” altid kan finde en vej ind forbi vores digitale mure – vores firewalls. Fra dette udgangspunkt tager vi vores forholdsregler, så vi præcist ved, hvad der skal gøres, hvis en ubuden gæst alligevel skulle finde vej ind. Dette princip kaldes ofte for “assume breach”, hvilket betyder, at vi opererer under antagelsen om, at vores forsvar allerede er blevet brudt.

I en zero trust-model låses alt ned, og hver eneste adgangsforsøg kræver verifikation. Dette indebærer en nøje gennemgang af brugere og deres rettigheder, hvor kun de mest nødvendige privilegier tildeles. Det sikrer, at kun de rigtige personer, under de rigtige omstændigheder, får adgang til de rigtige data – intet mere, intet mindre.

Ridderborgen genopfundet

Lad os vende tilbage til vores ridderborg-analogi. Med zero trust ville vi opdele borgen i flere mindre sektioner, hver med sin egen låste dør. Kun dem med et ægte ærinde (og de nødvendige rettigheder) kan bevæge sig fra det ene område til det andet. Dette tilføjer et ekstra lag af sikkerhed, da en indtrænger ikke længere frit kan bevæge sig rundt og udnytte systemets ressourcer.

Heldigvis er implementeringen af zero trust-princippet langt mindre komplekst i IT-verdenen, end det ville være i en fysisk ridderborg. Ved at anvende moderne teknologier og strategier kan vi opbygge en digital infrastruktur, hvor sikkerheden er indbygget på hvert niveau, og hvor hver handling kræver bekræftelse af identitet og rettigheder.

Sikkerhed

Det handler ikke kun om, hvordan man kommer ind, men hvad der sker, når man er kommet ind. Med zero trust sættes der firewall på alt, så det kun åbner for præcist det, der er brug for.

Generelt er sikkerhed blevet meget komplekst, og zero trust hjælper med at simplificere sikkerhed med en strategisk proces og automatiserede værktøjer, der verificerer alle aktiviteter, arbejder med kun at give adgang til det nødvendige og benytter avanceret undersøgelse og reaktion på trusler.

KvalitetsIT’s arbejde

I stedet for at man selv skal ændre alle individuelle steder via en brugergrænseflade, benytter vi en konfigurationsfil (Configuration-as-Code (CaC)), der automatisk bliver rullet ud og gør sig gældende alle de rigtige steder.

Typisk etablerer vi lidt a la nedenstående:

• Firewall mellem alle services, så man eksplicit skal åbne for adgang.
• Auth mellem alle services, så vi kun giver adgang til de rigtige brugere med de rigtige roller.
• TLS internt til f.eks. Kafka og Postgres, så kommunikationen til køer og databaser også er sikret.
• TLSv1.3 fra www til public services (vi tillader også TLSv1.2, det kommer dog an på kunden).
• Wireguard kryptering af netværk mellem alle VMer.
• Kryptering af data på disk.

Som det fremgår, så er der faktisk mange lag af låse i forhold til eksemplet med borgen.

Endnu mere konkret, så gør KvalitetsIT typisk som følger:

• Vi installerer og konfigurerer en firewall mellem alle services. Default er, at intet er åbent. Typisk er det Calico vi bruger til dette.
• Vi åbner for services og ikke porte.
• Vi autentificerer alle kald af services. Det kan være på roller eller endnu mere fingranuleret, hvis der er brug for det. Typisk anvender vi Keycloak og OIDC til dette.
• Alt kommunikation er TLS v1.3 beskyttet – også den interne, hvor det er muligt.
• Alt netværkstrafik mellem VM’er er krypteret med Wireguard.
• Data på diske er krypteret, hvis det er relevant.
• Automatisering af hele opsætningen af alt det ovenstående er nøglen til at få det til at fungere i praksis, så det hele ligger i konfigurationsstyringen og er under versionskontrol. Typisk Github.

Network policy

Et eksempel på en konfiguration, som vi sidder med, er konfigurationen af firewall (network policy). Den beskriver, at der må komme trafik ind fra internettet (ingress-nginx) og infrastrukturer til opsamlingen af metrics, og trafik ud til at lave DNS-opslag og beskedkø (Kafka). Resten er der ikke åbnet for.

Når man ser på ovenstående eksempel, er det klart, at automatiseringen ikke må undervurderes. Der er rigtig mange komponenter, der hver især skal åbnes for, for at det samlede system fungerer. Hvis man skal gøre det i hånden og ikke mindst vedligeholde det i hånden, så bliver det en kæmpestor opgave og risikoen for manuelle fejl er høj. Og laver man en fejl, er det faktisk rigtig rart blot at kunne gå tilbage til den tidligere version med et klik, frem for at skulle rode med Word-dokumenter og backup filer for at genskabe en tidligere version. Man kan gå tilbage til den tidligere version på et par minutter, frem for timer.

Vi implementerer zero trust med Kubernetes, der bruger container-baserede applikationer, der gør det nemmere at styre og overvåge.

Vi har sat Zero trust op for kommuner, regioner, små og store private virksomheder, og vi har sat det op inden for forskellige brancher herunder blandt andet healthcare.

Det er ikke nemt at holde styr på sikkerheden, og nogle gange kan man tage sig selv i at gøre alt arbejdet manuelt, fordi det virker mindre kompliceret end at lave et system, der gør det for dig. Derfor kan du overlade den generelle opsætning til os, mens du selv fokuserer på det forretningsnære.

Er du klar til at tage sikkerheden til det næste niveau og sikre dit Kubernetes cluster mod ubudne gæster? Kontakt KvalitetsIT på telefon 51148767 for en uforpligtende snak om, hvordan vi kan implementere en zero trust-arkitektur i din organisation. Sikkerhed er en rejse, ikke en destination, og med zero trust er du et skridt foran truslerne.