Det her sætter dig i stand til at køre en lille Linux-container på din Mac og give andre sikker adgang

Hvis du vil køre en app eller en lille service på din MacBook uden at åbne den for hele internettet, er en container en praktisk mellemvej: isoleret miljø, hurtigt at starte og nemt at skrotte igen.

Her får du et konkret setup, hvor du bygger en simpel Alpine Linux-container med Apples containerization CLI, og derefter forbinder til den via Tailscale SSH. Nøglen til Tailscale gemmes i Apple Keychain, så du undgår at lade auth keys ligge som løse tekstfiler.

Hvad du bygger: Mac som “host”, container som “mål”, Tailnet som privat net

Opsætningen bygger på tre idéer:

  • Apples containerization CLI bruges til at bygge og køre en lille Alpine Linux-container lokalt på din Mac.
  • Tailscale skaber et privat net (dit Tailnet), så du kan nå ressourcer uden at eksponere din Mac på åbne porte.
  • Tailscale SSH giver adgang til containeren via SSH over Tailnet – ideelt til en kollega, der sidder på en café eller i et fly, uden at resten af din Mac bliver “åben”.

Trin 1: Byg en simpel Alpine Linux-container med Apples containerization CLI

Målet er en minimalistisk container, du kan starte på din MacBook for at køre en applikation. Alpine Linux er populært til formålet, fordi den er lille og hurtig at hente og bygge.

Arbejdsgangen, som eksemplet viser, er i praksis:

  • Opret et lille container-projekt (fx en mappe til definition og build-artefakter).
  • Byg et Alpine-baseret image med Apples containerization CLI.
  • Start containeren og verificér, at den kører, før du tænker netværk og fjernadgang.

Vigtigt: Hold fokus på at få containeren til at køre stabilt lokalt først. Fjernadgang bliver kun mere irriterende at fejlsøge, hvis containeren i forvejen fejler ved opstart.

Hvad du bør tjekke, når containeren kører lokalt

  • Proces/kommando: Kører containeren stadig efter få sekunder, eller stopper den med det samme?
  • Log-output: Er der fejl, der peger på manglende pakker eller forkert entrypoint?
  • Den app du vil køre: Start med noget simpelt (fx en shell eller let service), og udbyg derefter.

Trin 2: Tilslut containeren via Tailscale – uden at eksponere din Mac

Når containeren kører, er målet at gøre den tilgængelig for en kollega i dit Tailnet. Fordelen ved Tailscale i den her kontekst er, at forbindelsen er privat og identitetsbaseret, uden at du skal åbne din MacBook for hele verden.

Eksemplet demonstrerer, at en kollega i dit Tailnet kan forbinde til containeren for at interagere med applikationen – selv fra netværk, du ikke kontrollerer, som en coffeeshop eller et fly – mens resten af MacBook’en ikke bliver eksponeret.

Hvad “ikke at eksponere resten af din MacBook” betyder i praksis

I stedet for at gøre din Mac til en offentlig server med åbne porte, giver du adgang til netop det, der er relevant: containeren og dens SSH-adgang via Tailscale. Det reducerer angrebsfladen og gør det nemmere at holde styr på, hvem der kan hvad.

Trin 3: Brug Tailscale SSH, og gem auth key i Apple Keychain

Fjernadgangen i eksemplet sker via Tailscale SSH. Det gør SSH-forbindelsen til en del af din Tailnet-adgang, og det er typisk den mest direkte måde at give “terminal-adgang” til en container.

Det centrale greb her er, at en Tailscale auth key gemmes i Apple Keychain. Det betyder, at du kan automatisere tilslutning/opsætning uden at efterlade nøgler i shell-historik, dotfiles eller et tilfældigt dokument på skrivebordet.

Hvorfor Keychain-lagring er worth it

  • Mindre rod: Du slipper for at håndtere nøgler som plain text.
  • Bedre drift: Det er lettere at standardisere på tværs af maskiner, især hvis flere i et team følger samme mønster.
  • Praktisk sikkerhed: Auth key’en ligger i et system, der allerede er designet til credentials.

Pro TipHvis du deler adgang med en kollega, så hold adgangen på container-niveau via Tailscale SSH i stedet for at give generel adgang til din Mac—det er den hurtigste måde at begrænse skaden, hvis nogen får “for meget” adgang.

Scenarie: Del en app i en container med en kollega på farten

Eksemplet beskriver et konkret use case: Du opretter en container på din MacBook for at køre en applikation. En kollega i dit Tailnet kan så logge ind i containeren og bruge applikationen, mens din Mac i øvrigt ikke er blottet for adgang udefra. Det er en ret elegant løsning, hvis du har behov for at “låne” compute eller køre et værktøj, uden at stå på mål for open ports, VPN-opsætninger eller NAT-mareridt.

Fejlfinding: Når det ikke virker, er det typisk én af de her ting

1) Containeren kører ikke stabilt

Hvis containeren stopper straks efter start, vil fjernadgang føles som et netværksproblem, selv om det i virkeligheden er et build/entrypoint-problem. Få den til at køre lokalt, inden du fejlsøger Tailscale.

2) Tailnet-adgang matcher ikke forventningen

Hvis kollegaen ikke er “i dit Tailnet” (eller ikke har de rigtige rettigheder), kan de ikke forbinde. Hele pointen er netop, at adgangen er begrænset til Tailnet-deltagere.

3) Auth key-håndtering driller

Når auth keys håndteres forkert, ender du ofte med en opsætning, der virker én gang og derefter fejler, eller en nøgle der ikke kan læses af den proces, der starter containeren. Brug Keychain-konceptet konsekvent, så du ikke blander metoder.

Min vurdering

Det mest interessante her er kombinationen af tre ting, der hver især er velkendte, men tilsammen giver en overraskende “ren” løsning: Apples containerization CLI til at køre noget isoleret lokalt, Tailscale til at gøre det privat tilgængeligt, og Keychain til at håndtere auth keys uden at opfinde din egen credential-håndtering.

Hvis du ofte har behov for at lade andre interagere med et værktøj, du kører på din egen maskine, er det her en pragmatisk måde at gøre det på: du deler adgang til det nødvendige (containeren), men du gør det uden at gøre resten af din MacBook til en offentlig ressource. Det er den slags setup, der ikke føles som en demo, når først det spiller—det føles som drift.

Næste skridt

Når du har grundopsætningen oppe at køre, kan du udvide containeren med din rigtige applikation og gøre adgangen mere målrettet: hold fokus på hvad kollegaen skal kunne, og lad resten blive inde på din egen maskine. Det er hele pointen med kombinationen af container + Tailnet.