Jeg er sikker på at dette har skjedd med deg: du prøver å sette sammen en beholder til personlig bruk, du vil gjøre den tryggere å bruke uprivilegerte containere Og plutselig befinner du deg fanget i en labyrint av tillatelsesfeil. Det er frustrerende å bruke timevis på å konfigurere mapper i brukerens hjemmekatalog, bare for å oppdage at containeren ikke kan skrive til dem, eller at når den gjør det, er de resulterende filene på verten ødelagt. umulig å administrere fordi de tilhører en fantombruker.
Realiteten er at selv om containerisering har fremskyndet programvarelevering, har det åpnet døren for betydelig risiko. Ifølge nyere data har de aller fleste produksjonsbilder [uklart - muligens "uklart" eller "uklart"] kritiske sårbarheterDette gjør sikkerhet til en ufravikelig pilar. Det handler ikke bare om å forhindre hackere fra å angripe oss, men om å forstå hvordan systemet fungerer. prosessisolasjon slik at infrastrukturen vår ikke blir en sil.
Forstå økosystemet for containersikkerhet
For å slutte å gjette med tillatelser, må vi først vite hva vi beskytter. En containers arkitektur er delt inn i flere kritiske lag. Først har vi bilde av beholderensom er den opprinnelige blåkopien; hvis denne er sårbar, vil alle instanser du distribuerer være usikre. Derfor er det viktig å bruke bilder av pålitelige baser og holde dem oppdatert.
Så den kjøretidsom fungerer som mekler mellom vertsoperativsystemet og applikasjonen. Hvis kjøretiden er utdatert, øker risikoen for en containerrømning øker dramatisk. Til dette må vi legge til orkestrering, som Kubernetes, der rollebasert tilgangskontroll (RBAC) Det er den eneste virkelige barrieren mot uautorisert tilgang til administrasjons-API-et.
Vi kan ikke glemme vertsoperativsystemHvis en angriper klarer å kompromittere vertskjernen, har de nøklene til hele domenet. Anbefalingen her er klar: bruk en minimalt med operativsystem for å redusere angrepsflaten. Til slutt er nettverket det vanligste inngangspunktet; nesten 30 % av bruddene skjer på grunn av tilkoblingsfeil, så nettverkssegmentering og TLS/SSL-kryptering De er obligatoriske.
Hodepinen med tillatelser og rotbrukeren
Det typiske problemet for hobbybrukere er arbeidsflyten med volumer. Du oppretter en mappe, monterer den, og så, boom!, en feil. tillatelse nektetDette skjer fordi mange containere som standard starter som root. Når du prøver å tvinge frem UID og GID på 0 For å få dem til å samsvare med vertsbrukeren din, lager du en farlig bro. Hvis containeren ikke lar deg konfigurere disse ID-ene, ender du opp med å kaste bort en ettermiddag på å prøve å finne ut hvilken intern bruker applikasjonen bruker til å utføre en chown Håndbok.
Den effektive løsningen er å anvende prinsippet om minste privilegiumDu bør ikke kjøre noe som root med mindre det er absolutt nødvendig. For å løse problemet med containeropprettede filer som du ikke kan slette på verten, er det viktig å konfigurere Dockerfile med følgende instruksjon: BRUKER, og definerer en bruker uten rettigheter før applikasjonen starter.
Hvis du bruker Podman, konseptet med rotløse beholdere Det er innebygd og veldig nyttig, men det krever at du forstår hvordan vertsbrukere er tilordnet containerbrukere. For å forhindre at tillatelser kommer ut av kontroll, bør applikasjonen ideelt sett være designet for å skrive til bestemte ruter, og at volumkartlegging Det gjøres med tanke på den virkelige UID-en til brukeren som starter prosessen.
Strategier for å bygge pansrede bilder
Hvis du vil slutte å lide, må du endre måten du konstruerer bildene dine på. En brutalt effektiv teknikk er... flertrinnsbyggI bunn og grunn bruker du et tungt bilde med alle byggeverktøyene for å generere binærfilen, og deretter kopierer du bare den filen til et endelig bilde. ekstremt lett.
Du kan til og med gå lenger ved å bruke bildet skraperDette skaper en container som har absolutt ingenting: ingen skall, ingen pakkebehandler, bare applikasjonen din. Dette gjør det praktisk talt umulig for en angriper å utføre ondsinnede kommandoer hvis de klarer å komme seg inn, siden Det finnes ingen kommandotolk tilgjengelig.
Et annet sikkerhetstiltak er å rense bildet av alle binære filer med tillatelser setuid eller setgidDisse tillatelsene tillater at en fil kjøres med rettighetene til fileieren og ikke brukeren som starter den, noe som er en motorvei for... privilegieeskaleringEn enkel kommando for å søke etter og fjerne disse bitene under bildebygging kan spare deg for mye problemer.
Farene ved privilegert modus og funksjonene til Linux
Noen ganger, i desperasjon over å ikke kunne løse et tillatelsesproblem, faller vi for fristelsen til å bruke flagget –privilegerteGlem å gjøre det. Privilegert modus bryter containerens isolasjon og gir deg full tilgang til vertens enheter. Det er som å gi nøklene til huset ditt til en fremmed bare fordi de ikke visste hvordan de skulle åpne hageporten.
I stedet bør du leke med Linux-funksjonerDocker tildeler et sett med standardtillatelser (som CAP_CHOWN eller CAP_NET_RAW). Hvis applikasjonen din ikke trenger å manipulere nettverket på et lavt nivå, er den smarteste tilnærmingen eliminer unødvendige funksjoner og legg bare til de som er strengt nødvendige av --cap-add.
For de som håndterer mer seriøse miljøer, finnes det autorisasjonsplugins som for eksempel opa-docker-authz. Disse tillater avlytting av anrop til Docker-daemonens API og blokkering av ethvert forsøk på å starte en container i privilegert modus, slik at ingen, selv ved en feiltakelse, lar døren stå åpen for verten.
Miljøoptimalisering og vedlikehold
Ikke heng deg opp i bildestørrelsen på 5 MB når du bruker Alpine Linux hvis det forårsaker kompatibilitetsproblemer med bibliotekene. Noen ganger er et litt større Debian-bilde å foretrekke. stabilisert og kjent av teamet. Det som er kritisk er å implementere en sårbarhetsskanning Automatisert CI/CD-pipeline for å oppdage CVE-er før bildet når produksjonsprosessen.
Når det gjelder lagring, hindrer det applikasjonen i å skrive til rotfilsystemet. Konfigurer skrivebeskyttet filsystem (rootfs) og definerer spesifikke volumer kun for dataene som må lagres. Dette er ikke bare sikrere, men det tvinger også frem en renere arkitektur og eiendomsløstilrettelegging for horisontal skalering.
For planlagte prosesser, ikke legg en cron-jobb inne i nettstedsbeholderen. Den gylne regelen er én prosess per beholderDen reneste tilnærmingen er å bruke appens image til å starte en flyktig container som utfører oppgaven og deretter ødelegger seg selv, eller å administrere cron-koden fra verten ved å kalle containermotoren ved hjelp av kommandoer.
Containersikkerhet er en kontinuerlig prosess som innebærer å eliminere root-tilgang, begrense kjernefunksjoner og fjerne unødvendige verktøy fra containeravbildninger. Ved å kombinere uprivilegerte brukere med runtime-herding og konstant overvåking oppnås et miljø der funksjonaliteten ikke kompromitterer vertssystemets integritet.
Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.