‫Volgende op.
‫Dit is een grote.
‫Voer uw apps niet uit als root in de container als u
‫dit kunt vermijden.
‫Als ik dit heel snel doe, op een kleine
‫demo hier.
‫Oke. Ik heb Docker draaiende, tenminste dat zou
‫ik moeten doen. Oke.
‫En als ik gewoon ren...
‫Als ik gewoon Nginx gebruik, goed, en ik
‫doe een docker-top op
‫die container.
‫Wat zien we hier?
‫In de container startte Nginx een proces bij
‫root en creëerde het vervolgens een nieuw
‫proces als een niet-rootgebruiker.
‫Kijk hoe die gebruiker 101 is.
‫Dit is gebruikelijk bij veel op daemon gebaseerde programma's
‫zoals MySQL, Postgres, Nginx.
‫Veel van hen die geen programmeertalen zijn, zullen
‫dit automatisch doen. Dit is dus veilig.
‫Wat dit doet, is dat Nginx werkprocessen kan voortbrengen
‫die niet als root worden uitgevoerd om het
‫grootste deel van het werk te doen.
‫Ze hebben dus één hoofdproces dat als root draait, maar dat is
‫niet wat verbindingen accepteert en het grootste deel van
‫het werk doet. Het meeste
‫daarvan zit in deze werkprocessen. Ze werken als een normale
‫gebruiker, wat betekent dat als er een kwetsbaarheid in Nginx
‫is, de kans groot is dat wanneer
‫inkomende verbindingen binnenkomen en iemand probeert het Nginx HTTP-protocol
‫te misbruiken, het zal worden vergrendeld of vastgezet in deze gebruiker
‫op .. . meestal tenzij er
‫een ernstige kwetsbaarheid is.
‫Hier beneden, en dan zijn ze beperkt tot wat ze
‫kunnen doen, toch. Zelfs als ze dat proces op de
‫een of andere manier zouden overnemen, zijn ze als gebruiker nog steeds beperkt.
‫Dit is dus oké.
‫Dit draait nog steeds niet als echte
‫root in de container. Waar ik het echt over
‫heb, is dat als
‫je een Python-app of een Node-app of
‫iets dergelijks zou draaien waar het een programmeertaal is, dat dan
‫iets is dat standaard root is omdat de
‫programmeertaal in de container dat niet doet. t weet hoe
‫uw programma werkt. Het weet niet wat je wilt dat het doet.
‫Dus het gaat standaard root doen, en
‫dat gaat meer over applicatiecompatibiliteit.
‫We zouden kunnen zeggen dat we dit standaard veilig willen
‫hebben, maar Docker heeft ervoor gekozen om al deze officiële containers echt als
‫root voor de programmeertalen te laten draaien.
‫Laten we dat gaan bekijken.
‫Oeps. Niet die.
‫Firefox.
‫Dus als we, laten we zeggen, naar Hub gaan.
‫Laten we gewoon Node doen.
‫Dit is gebruikelijk in de meeste talen.
‫Ik ga gewoon Node als voorbeeld nemen.
‫Inside Node,
‫als ik hier naar een van de Dockerfiles ga.
‫Dan zoek ik naar gebruiker.
‫Je zult merken dat ik eigenlijk niets vind.
‫Het is alleen deze gebruiker die hier toevoegt.
‫Je zult merken dat het dit doet, toch.
‫Het voegt technisch gezien een groep toe met de naam Node en het voegt
‫een gebruiker toe met de naam Node.
‫Als je de rest van dit bestand doorzoekt, realiseer je je dat het
‫nooit verandert in die gebruiker met de strofe U S
‫E R, toch.
‫Je zou het gebruikersknooppunt daar ergens als een regel moeten zien.
‫Dat doen ze niet omdat dat jouw taak is.
‫Dus, wat je zou moeten doen in
‫je down-level Dockerfile. Dus elk Dockerbestand
‫dat u maakt van deze officiële afbeeldingen
‫voor programmeertalen, zou u moeten profiteren van de gebruikers
‫die ze voor u maken. Als ze die gebruikers niet maken, kunt u er
‫zelf een maken op dezelfde manier. Je kunt dit
‫kleine ding met twee regels gewoon stelen en veranderen in
‫de gebruiker die je wilt. Als het voor Python is,
‫zou je het gewoon Python-gebruiker kunnen noemen, wat dan ook.
‫Als u dat doet, zullen de toepassingen die
‫u uitvoert niet als root in de container worden
‫uitgevoerd. Als
‫u alleen een standaard Node-app uitvoert, gebruikt deze standaard de
‫rootgebruiker in een container.
‫Waarom is dit zo belangrijk?
‫Nou, twee dingen.
‫Ten eerste, als iemand in staat is om je applicatie
‫te doorbreken en je applicatie te hacken en toegang te
‫krijgen tot het bestandssysteem, als ze... als die applicatie root is, dan
‫kunnen ze in de container doen wat ze willen in
‫de container, toch. Ze kunnen bestanden
‫naar het bestandssysteem schrijven. Ze kunnen meer programma's in die container
‫installeren die wanneer ze maar willen in die container kunnen draaien.
‫Dus we willen echt niet dat ze dat doen.
‫We hebben ze liever heel beperkt.
‫Dus, als je applicaties het ondersteunen,
‫weet je, doe dit. Je zorgt er in principe voor dat je
‫de gebruiker beschikbaar hebt.
‫Dan heb ik hier een voorbeeld van DockerCon.
‫Bij DockerCon had ik een heel gesprek over Node. js, en een
‫van de onderwerpen ging over de gebruiker.
‫Eens kijken of ik dat kan vinden.
‫Zie je wat ik hier deed? Het is een vrij eenvoudig bestand.
‫Ik ga deze linken en plaatsen.
‫In dit Dockerbestand.
‫Dus in deze Dockerfile heb ik...
‫Ik heb geen gebruiker gemaakt omdat de Node-afbeelding deze
‫al voor mij heeft gemaakt. Ik ga gewoon over op gebruikersknooppunt.
‫Dan installeer ik mijn pakketten met deze twee regels, en later
‫ga ik het uitvoeren.
‫Je zult merken dat ik de
‫chown-optie in mijn kopieeropdrachten moet gaan gebruiken om ervoor te zorgen dat
‫mijn bestanden nu dezelfde gebruiker zijn als de gebruiker die mijn
‫programma zal uitvoeren. Anders kunnen er problemen zijn,
‫toch. Mijn sollicitatie waarschijnlijk... als
‫het de bestanden niet kan lezen, dan kan het het niet uitvoeren, toch.
‫Dus ik heb de wijzigingen nodig die machtigingen.
‫Ik kan dat doen met een one-liner op een kopieeropdracht.
‫Je zult hier ook zien dat ik de map aan het maken
‫ben en deze ook chown, zodat wanneer de app wordt gekopieerd,
‫ik er zeker van wil zijn, extra zeker, dat
‫de machtigingen aanwezig zijn zodat deze kan schrijven.
‫Omdat op het moment dat ik deze gebruiker
‫verander, dit kopieercommando, of specifiek dit run-commando, als die gebruiker
‫wordt uitgevoerd. Als het geen machtigingen heeft
‫om naar de mappen te schrijven, zal het ook mislukken.
‫Dus de reden dat Docker dit niet voor je doet, is omdat
‫ze weten dat je spullen waarschijnlijk kapot gaan.
‫U moet dus deze extra stappen nemen.
‫Maar, het is niet zo moeilijk. Het is echt niet.
‫Je kunt waarschijnlijk al deze tests in een dag doen, en
‫dan wil je je systemen door volledige CI en volledige tests
‫op je servers laten lopen, want soms, en PHP is een van
‫degenen die hier slecht in is.
‫PHP houdt ervan om een heleboel logbestanden uit te voeren en een
‫heleboel naar schijf te schrijven.
‫Echt, alles dat gebruikersuploads toestaat, zal naar
‫schijf schrijven. Je moet er dus
‫voor zorgen dat die machtigingen correct zijn, zodat wanneer mensen bestanden schrijven, laten
‫we zeggen dat ze een WordPress-blog hebben.
‫Die WordPress-blog zal naar schijf schrijven wanneer gebruikers
‫afbeeldingen uploaden naar hun blog.
‫U wilt er zeker van zijn dat die machtigingen werken.
‫Je zult dus zeker wat moeten testen.
‫Als je dat eenmaal hebt gedaan, zal je applicatie nu
‫niet als root worden uitgevoerd. Het kan dus geen volledige controle
‫hebben in de container. De andere reden
‫waarom je dit wilt doen, is dat als er een
‫kwetsbaarheid is in Linux, wat zeldzaam is, of Docker, wat ook
‫erg zeldzaam is, de kans kleiner is dat ze
‫uit deze container zullen breken. Dat is maar één keer gebeurd, waarvan
‫ik me heel goed bewust ben, en ik heb er hier een klein
‫beetje van gedocumenteerd.
‫Vuile KOE. Dirty COW was
‫een kwetsbaarheid in Linux waarmee je uit
‫een
‫container kon komen, toch. Het veranderen van je gebruiker
‫hier, zou
‫niet noodzakelijk het hele probleem oplossen,
‫maar het deed zeker geen pijn.
‫Tegen andere kwetsbaarheden zou het waarschijnlijk beschermen.
‫Maar dit is een best practice.
‫Ik denk dat als je een beveiligingsteam hebt, ze
‫erop zullen aandringen dat je de dingen niet als root uitvoert.
‫Dus dat zou je
‫doen.