Jag är säker på att detta har hänt dig: du försöker montera en behållare för personligt bruk, du vill göra den säkrare att använda oprivilegierade behållare Och plötsligt befinner du dig fångad i en labyrint av behörighetsfel. Det är frustrerande att spendera timmar på att konfigurera mappar i användarens hemkatalog bara för att upptäcka att containern inte kan skriva till dem, eller att när den gör det är de resulterande filerna på värden skadade. omöjlig att hantera eftersom de tillhör en fantomanvändare.
Verkligheten är att även om containerisering har påskyndat programvaruleverans, har det öppnat dörren för betydande risker. Enligt aktuell data innehåller den stora majoriteten av produktionsavbildningar [oklart - möjligen "oklart" eller "oklart"] kritiska sårbarheterDetta gör säkerhet till en icke-förhandlingsbar grundpelare. Det handlar inte bara om att förhindra hackare från att attackera oss, utan om att förstå hur systemet fungerar. processisolering så att vår infrastruktur inte blir en sil.
Förstå containersäkerhetsekosystemet
För att sluta gissa med behörigheter måste vi först veta vad vi skyddar. En containers arkitektur är uppdelad i flera kritiska lager. Först har vi bild av behållarenvilket är den ursprungliga ritningen; om detta är sårbart kommer alla instanser du driftsätter att vara osäkra. Det är därför det är viktigt att använda bilder på betrodda baser och hålla dem uppdaterade.
Sedan körningsom fungerar som mellanhand mellan värdoperativsystemet och applikationen. Om körtiden är föråldrad minskar risken för en containerflykt ökar dramatiskt. Till detta måste vi lägga till orkestrering, såsom Kubernetes, där rollbaserad åtkomstkontroll (RBAC) Det är det enda verkliga hindret mot obehörig åtkomst till hanterings-API:et.
Vi kan inte glömma värdoperativsystemOm en angripare lyckas kompromettera värdkärnan har de nycklarna till hela domänen. Rekommendationen här är tydlig: använd en minimalt med operativsystem för att minska attackytan. Slutligen är nätverket den vanligaste ingångspunkten; nästan 30 % av intrången sker på grund av anslutningsfel, så nätverkssegmentering och TLS/SSL-kryptering De är obligatoriska.
Huvudvärken med behörigheter och root-användaren
Det typiska problemet för hobbyister är arbetsflödet med volymer. Man skapar en mapp, monterar den, och sedan, pang!, ett fel. tillstånd nekadDetta händer eftersom många containrar som standard startar som root. När du försöker tvinga fram UID och GID vid 0 För att få dem att matcha din värdanvändare skapar du en farlig brygga. Om containern inte tillåter dig att konfigurera dessa ID:n kommer du att slösa bort en eftermiddag på att försöka lista ut vilken intern användare applikationen använder för att utföra en chown manual.
Den effektiva lösningen är att tillämpa principen om minsta privilegiumDu bör inte köra något som root om det inte är absolut nödvändigt. För att lösa problemet med containerskapade filer som du inte kan ta bort på värden är det viktigt att konfigurera Dockerfile med följande instruktion: ANVÄNDARE, definierar en användare utan behörigheter innan applikationen startas.
Om du använder Podman, konceptet med rotlösa behållare Det är inbyggt och mycket hjälpsamt, men det kräver att du förstår hur värdanvändare mappas till containeranvändare. För att förhindra att behörigheterna går överstyr bör applikationen helst vara utformad för att skriva till specifika rutter och att volymmappning Det görs med hänsyn till användarens verkliga UID som startar processen.
Strategier för att bygga pansarbilder
Om du vill sluta lida måste du ändra hur du konstruerar dina bilder. En brutalt effektiv teknik är... flerstegsbyggnaderI grund och botten använder du en kraftig avbildning med alla byggverktyg för att generera binärfilen, och sedan kopierar du bara den filen till en slutlig avbildning. extremt lätt.
Du kan till och med gå längre med hjälp av bilden repaDetta skapar en container som inte har någonting alls: inget skal, ingen pakethanterare, bara din applikation. Detta gör det praktiskt taget omöjligt för en angripare att köra skadliga kommandon om de lyckas ta sig in, eftersom Det finns ingen kommandotolk tillgängliga.
En annan säkerhetsåtgärd är att rensa avbildningen av alla binärfiler med behörigheter setuid eller setgidDessa behörigheter tillåter att en fil körs med filägarens behörigheter och inte användarens som startar den, vilket är en motorväg för... privilegieupptrappningEtt enkelt kommando för att söka efter och ta bort dessa bitar under bildbyggandet kan bespara dig mycket problem.
Farorna med privilegierat läge och Linux funktioner
Ibland, av desperation över att inte kunna lösa ett behörighetsproblem, faller vi för frestelsen att använda flaggan -privilegieradGlöm bort det. Privilegierat läge bryter containerns isolering och ger dig fullständig åtkomst till värdens enheter. Det är som att ge husnycklarna till en främling bara för att de inte visste hur man öppnar trädgårdsgrinden.
Istället borde du leka med Linux-funktionerDocker tilldelar en uppsättning standardbehörigheter (som CAP_CHOWN eller CAP_NET_RAW). Om din applikation inte behöver manipulera nätverket på en låg nivå är det smartaste tillvägagångssättet eliminera onödiga funktioner och lägg endast till de som är absolut nödvändiga enligt --cap-add.
För de som hanterar mer seriösa miljöer finns det auktoriseringsplugins såsom opa-docker-authz. Dessa tillåter avlyssning av anrop till Docker-daemonens API och blockering av alla försök att starta en container i privilegierat läge, vilket säkerställer att ingen, inte ens av misstag, lämnar dörren öppen för värden.
Miljöoptimering och underhåll
Häng dig inte upp på 5 MB-avbildningsstorleken när du använder Alpine Linux om det orsakar kompatibilitetsproblem med biblioteken. Ibland är en något större Debian-avbildning att föredra. stabiliserad och känd av teamet. Det avgörande är att implementera en sårbarhetsskanning Automatiserad CI/CD-pipeline för att upptäcka CVE:er innan avbildningen når produktionsläget.
När det gäller lagring förhindrar det att applikationen skriver till rotfilsystemet. Konfigurera skrivskyddat filsystem (rootfs) och definierar specifika volymer endast för de data som behöver sparas. Detta är inte bara säkrare utan det tvingar också fram en renare arkitektur och dödsbolösunderlättar horisontell skalning.
För schemalagda processer, placera inte ett cron-jobb inuti webbplatsens container. Den gyllene regeln är en process per behållareDet renaste tillvägagångssättet är att använda din apps avbildning för att starta en efemär container som utför uppgiften och sedan förstör sig själv, eller att hantera cron-funktionen från värden genom att anropa containermotorn med hjälp av kommandon.
Containersäkerhet är en pågående process som innebär att eliminera root-åtkomst, begränsa kärnfunktioner och ta bort onödiga verktyg från containeravbildningar. Genom att kombinera oprivilegierade användare med runtime-härdning och konstant övervakning uppnås en miljö där funktionaliteten inte äventyrar värdsystemets integritet.
Passionerad författare om bytesvärlden och tekniken i allmänhet. Jag älskar att dela med mig av min kunskap genom att skriva, och det är vad jag kommer att göra i den här bloggen, visa dig alla de mest intressanta sakerna om prylar, mjukvara, hårdvara, tekniska trender och mer. Mitt mål är att hjälpa dig att navigera i den digitala världen på ett enkelt och underhållande sätt.