Vraag Hoe omgaan met beveiligingsupdates binnen Docker-containers?


Bij het inzetten van applicaties op servers is er meestal een scheiding tussen wat de applicatie bundelt met zichzelf en wat het verwacht van het platform (besturingssysteem en geïnstalleerde pakketten) om te bieden. Een punt hiervan is dat het platform onafhankelijk van de applicatie kan worden bijgewerkt. Dit is bijvoorbeeld handig wanneer beveiligingsupdates dringend moeten worden toegepast op pakketten die door het platform worden geleverd zonder de hele applicatie opnieuw te hoeven bouwen.

Traditioneel worden beveiligingsupdates toegepast door eenvoudigweg een pakketbeheeropdracht uit te voeren om bijgewerkte versies van pakketten op het besturingssysteem te installeren (bijvoorbeeld "yum-update" op RHEL). Maar met de komst van containertechnologie zoals Docker, waar containerafbeeldingen in wezen beide applicaties bundelen en het platform, wat is de canonieke manier om een ​​systeem met containers up-to-date te houden? Zowel de host als containers hebben hun eigen, onafhankelijke sets van pakketten die moeten worden bijgewerkt en bijgewerkt op de host en die geen pakketten in de containers zullen bijwerken. Met de release van RHEL 7, waar Docker-containers vooral worden gebruikt, is het interessant om te horen wat Redhat's aanbevolen manier is om met beveiligingsupdates van containers om te gaan.

Over een paar opties nadenken:

  • Als pakketbeheer pakketten bijwerkt op de host, worden de pakketten in de containers niet bijgewerkt.
  • Het opnieuw genereren van alle containervideo's om updates toe te passen, lijkt de scheiding tussen de toepassing en het platform te doorbreken (voor het bijwerken van het platform is toegang nodig tot het applicatiebouwproces dat de Docker-images genereert).
  • Het uitvoeren van handmatige opdrachten in elk van de actieve containers lijkt omslachtig en wijzigingen kunnen worden overschreven wanneer containers de volgende keer worden bijgewerkt vanuit de artefacten voor het vrijgeven van de toepassing.

Geen van deze benaderingen lijkt dus bevredigend.


103
2017-07-08 21:54


oorsprong


Het beste idee dat ik tot nu toe heb gezien, is Project Atomic. Ik denk het niet heel klaar voor prime time hoor. - Michael Hampton♦
Valko, met welke workflow heb je het gedaan? Ik run langetermijncontainers (bijvoorbeeld php-cgi) en wat ik tot nu toe heb gevonden is: docker pull debian/jessie om de afbeelding bij te werken, vervolgens mijn bestaande afbeelding (en) opnieuw te maken, stop dan de containers en voer ze opnieuw uit (met de nieuwe afbeelding). De afbeeldingen die ik maak hebben dezelfde naam als de vorige, dus het starten gebeurt via het script. Ik verwijder vervolgens "naamloze" afbeeldingen. Ik zou zeker een betere workflow waarderen. - miha
miha: Dat klinkt hetzelfde als wat ik uiteindelijk heb gedaan. In principe voortdurend updaten en opnieuw opbouwen van alle afbeeldingen als onderdeel van het maken van nieuwe releases. En het opnieuw opstarten van de containers met behulp van de nieuwe afbeeldingen. - Markus Hallmann
Het beste antwoord hier helpt veel omdat er een script is met de belangrijkste commandolijnen om precies te doen wat Johannes Ziemke zei: - Hudson Santos


antwoorden:


Een Docker image bundelt applicatie en "platform", dat klopt. Maar meestal bestaat het beeld uit een basisafbeelding en de daadwerkelijke toepassing.

De standaard manier om beveiligingsupdates af te handelen, is dus om de basisafbeelding bij te werken en vervolgens uw toepassingsafbeelding opnieuw te maken.


43
2017-08-12 11:41



Bedankt, dit klinkt redelijk. Wilt u gewoon nog steeds het platform bijwerken, dan zou het niet nodig zijn om de hele applicatie opnieuw te verpakken (denk bijvoorbeeld aan het opnieuw opbouwen van 100 verschillende applicatie-afbeeldingen vanwege een enkel basisbeeld dat een update krijgt). Maar misschien is dit onvermijdelijk met de Docker-filosofie om alles samen te bundelen in één afbeelding. - Markus Hallmann
@ValkoSipuli Je zou altijd een script kunnen schrijven om het proces te automatiseren. - dsljanus
Waarom niet apt-get upgrade, dnf upgrade, pacman -syu, etc equivalent in de container? Je zou zelfs een shellscript kunnen maken dat dat doet en dan voert de toepassing uit en gebruikt die vervolgens als het entrypoint van de container, zodat wanneer de container wordt gestart / opnieuw wordt gestart, alle pakketten worden bijgewerkt. - Arthur Kay
@ArthurKay Twee redenen: 1) U blaast de containergrootte op, omdat alle pakketten die worden geüpgraded, worden toegevoegd aan de containernaag terwijl het verouderde pakket in de afbeelding blijft. 2) Het verslaat het grootste voordeel van (container) afbeeldingen: de afbeelding die u uitvoert is niet dezelfde die u bouwt / test omdat u pakketten tijdens runtime wijzigt. - Johannes 'fish' Ziemke
Er is een ding dat ik niet begrijp: als u een bedrijf bent dat een stuk software koopt dat wordt verzonden als container voor een docker, moet u wachten totdat de fabrikant van de software het toepassingspakket opnieuw opbouwt telkens wanneer een beveiligingsprobleem naar voren komt ? Welk bedrijf zou op die manier de controle over hun open kwetsbaarheden opgeven? - Sentenza


De containers zouden lichtgewicht en uitwisselbaar moeten zijn. Als uw container een beveiligingsprobleem heeft, herbouwt u een versie van de container die is gepatcht en de nieuwe container heeft geïmplementeerd. (in veel containers wordt een standaardbasisafbeelding gebruikt die standaardpakketbeheerprogramma's gebruikt, zoals apt-get om hun afhankelijkheden te installeren, bij het opnieuw opbouwen worden de updates opgehaald uit de opslagplaatsen)

Terwijl je in containers zou kunnen patchen, zal dat niet goed schalen.


6
2017-10-03 19:44





Dit wordt automatisch verwerkt in SUSE Enterprise Linux met behulp van zypper-docker (1)

SUSE / zypper-docker

Docker-snelstart


1
2018-05-08 17:05





Allereerst zullen veel van uw updates die u traditioneel in het verleden hebt uitgevoerd, gewoon niet in de container zelf zijn. De container moet een redelijk lichte en kleine subset zijn van het volledige bestandssysteem dat u in het verleden gewend bent te zien. De pakketten die u moet bijwerken, zijn die die deel uitmaken van uw DockerFile en aangezien u DockerFile hebt, zou u in staat moeten zijn om die pakketten en container-ID's bij te houden die updates nodig hebben. De gebruikersinterface van Cloudstein die binnenkort wordt uitgebracht, houdt deze DockerFile-ingrediënten voor u bij, zodat u het updateplan kunt bouwen dat het beste past bij hun containers. Ik hoop dat dit helpt


0
2017-07-08 23:23