Ze doen het om andere redenen.

docker is een container
kubernetes is een 'orkestratie platform' voor docker containers .

Een container is (min of meer) een lichtgewicht VM .
Zie bv https://www.backblaze.com/blog/vm-vs-containers/

Zelden of nooit worden dergelijke infrastructuur keuzes primair gemaakt 'omdat het veel veiliger is'.
Dat kan een bij-effect zijn, of een 'pluspunt' bij een afweging van een paar opties.
(dat moeten security mensen nogal eens leren , dat hun onderwerp niet altijd en overal de doorslag geeft) .

Je zou kunnen argumenteren dat kiezen voor containers leidt naar een infrastructuur welk elk bouwblokje een eigen container is, en dat dit het risico van breach/escalatie beperkt omdat vanuit een component in een container het minder makkelijk is om een component in een andere container te misbruiken.
(waar het door-escaleren vanuit een applicatie makkelijker is als dezelfde server meer functies heeft en uitgebreider opgezet is ).
Verder kun je argumenteren dat het container model meer leidt tot goed managebare 'OS platformen' (de containers delen typisch een standaard image) dan VMs die specifiek gebouwd en getweaked worden voor een set van functies waarna updates een zwaardere procedure zijn.

Maar dat zijn allemaal argumenten met veel slagen om de arm en "het hangt van specifieke omstandigheden af" .

Strikt genomen zijn twee VMs waarschijnlijk beter van elkaar geisoleerd dan twee containers (en met wat we zien in Meltdown/Spectre e.a.) - zelfs daar kunnen side channels tussen bestaan.

Het is niet vanwege veiligheid, het is omdat het deployment process volledig geautomatiseerd is en omdat Kubernetes platform onafhankelijk is (je kunt Kubernetes draaien op physical, VMs of VMs in cloud, etc.), etc.

Niet alleen voor Docker.

https://joejulian.name/post/kubernetes-container-engine-comparison/

Een standard VM moet om te kunnen werken hardware emuleren, dit brengt altijd vertraging
met zich mee. Een container (LXC bijvoorbeeld) draait gewoon op de kernel van het host
systeem maar heeft zijn eigen systeem (contained) en is dus vele malen sneller en beter
in performance..

Ja dit verhaal klopt maar vanuit een security perspective is een VM veiliger toch denk ik?

Kan je beter een VM in een container aanmaken of Container in een VM vanuit security perspective?

Zijn er Virtual machines voor Chrome OS of is dat niet nodig omdat Google Chrome OS default al erg veilig is?

Het leek me grappig om onder Chrome te spelen met wat anders zoals Ubuntu of BSD

Ik zou zeker wel een VM gebruiken! Maar kan dat uberehaupt in chromeos?

Hoe superieur is dit ten opzichte van dat Qubes OS ?

Docker is bedoeld voor micro-services niet als vervanging van een VM of zo, sterker nog, docker draait heel vaak op een VM als micro-service.

Ooit had je mainframes.
- lastig om de silo's binnen de organisaties te laten samenwerken
- een foute aanname: informatiebeveiliging is iets voor de techneuten niet voor de organisatie.
- de techniek wordt als interessant gezien, echter niet nuttig voor de organisatie om er kennis van te hebben.
- de kostenverdeling een lastig aspect

Oplossing voor de kostenverdeling en samenwerking:
-> geef elke silo een eigen machinepark met eigen zeggenschap.
Resultaat:
- lastig om de silo's binnen de organisaties te laten samenwerken
- een foute aanname: informatiebeveiliging is iets voor de techneuten niet voor de organisatie.
- de techniek wordt als interessant gezien, echter niet nuttig voor de organisatie om er kennis van te hebben.
- de kosten rijzen tot onverwachte hoogtes. Oorzaak het aantal fysieke machines

Oplossing voor de onverwacht hoge kosten:
-> virtualiseer al die machines in de hoop dat je de hardware kosten (en beheer) omlaag brengt.
Resultaat:
- lastig om de silo's binnen de organisaties te laten samenwerken
- een foute aanname: informatiebeveiliging is iets voor de techneuten niet voor de organisatie.
- de techniek wordt als interessant gezien, echter niet nuttig voor de organisatie om er kennis van te hebben.
- de kosten rijzen tot onverwachte hoogtes wegens het complexere beheer en soa.

Oplossing voor de onverwacht hoge kosten:
-> virtualiseer "de applicaties" ofwel neem aan dat de die ingekochte standaard tools de applicaties van de organisatie zijn.
Dit is docker / kubernetes, pas rectn technisch mogelijk met groupd
https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf
De clou zit in systemd en cgroups https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 , https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/setting_realtime_scheduler_priorities
Resultaat:
- lastig om de silo's binnen de organisaties te laten samenwerken
- een foute aanname: informatiebeveiliging is iets voor de techneuten niet voor de organisatie.
- de techniek wordt als interessant gezien, echter niet nuttig voor de organisatie om er kennis van te hebben.
- de kosten rijzen tot onverwachte hoogtes omdat de cocker containers niet de applicaties van de organisatie zijn

Oplossing voor de onverwacht hoge kosten:
-> Ga de ICT als dienstverlening voor en van de organisatie zien.

WTF Karma, weer geen touw aan vast te knopen.

lijkt minder kostbaar, meer 'gebruiksvriendelijk' ook en niet alleen qua personeel.

Inderdaad, ik snap er ook niets van. En weer totaal off-topic, OP vraagt iets over Docker en Kubernets, en Karma4 begint over mainframes en silos? All die jaren dat ik in de IT werk als software engineer, heb ik nog nooit een silo gezien... maar misschien verklaart dat een hoop van Kara4's kennis, dat lijkt een zekere niche-markt te zijn ofzo.

De organisaties waarbij gemak of kosten de bepalende factor zijn geweest ten opzichte van security zijn hier regelmatig in het nieuws. Security is niet iets dat je op het laatst toevoegt, dat weef je vanaf het begin in je organisatie en architectuur. Of niet.

Als je de silo's van bedrijven niet kent heb je niets in de ICT te zoeken. Het is het euvel van gebrek aan samenwerking, gebrek aan strategie en meer van dat soort negatieve zaken.
https://www.managementissues.com/index.php/organisatiemanagement/76-management/165-het-siloprobleem
Docker - kubernetes is het zoveelste dat beweert een oplossing te bieden waar men door gebrek aan samenwerking nog nooit echt een oplossing in beeld heeft gehad.
Alleen de hobbyist dan wel gewillige "setup enter enter" uitvoerder zal het als onderdeeltje onderin in de silo niet zien.

Het idee met Docker is ook dat je hele uitgeklede containers hebt, dus een zo kaal mogelijk OS container (zoals Alpine) met bijv een tomcat en een war en dat is het, dit heeft ook security impact: minder draaien betekend vaak ook minder aanval vectoren. Punt is wel dat er outdated troep docker images bestaan die onveilig zijn en dat soms men niet weet wat men doet.
Docker socket misbruik komt ook steeds vaker voor waardoor men van de ene container zo in de andere kan komen of op de host.

Ik ken Docker en Kubernets niet. Hoe vergelijkt dit met Qubes (in 2 zinnen of zo)?

Ik ken Qubes niet, hoe vergelijkt dit met kubes of kwiebus?

https://lmgtfy.com/?q=what+is+docker+and+kubernetes

Sorry hoor Karma4, ik heb het artikel even gelezen, interessant, en er staat zinnige informatie in. Maar het komt uit: "marketing als kennisnetwerk", en als ik het "siloprobleem" google, vindt ik sites over management en marketing. Oftewel het is weer zo'n kreet die in de bullshit-bingo kan worden opgenomen. Ik zei dat ik software engineer was, dus vind je het gek dat ik die loze marketing kreten niet ken? Om nu te beweren dat ik niet in de IT thuishoor moet je zelf weten, maar ik begin steeds meer te begrijpen op welke afdeling jij "werkt", het is in ieder geval een afdeling waar je heel hard de bel van e kerk kunt horen, maar die klepel zit toch echt in een ander gebouw.

karma4 zit inderdaad duidelijk aan de organisatorische kant en niet in de techniek.

Maar de term 'silo' in IT land is wel vrij algemeen. Ook al ken je dan blijkbaar de term niet, het fenomeen zul je beslist ervaren hebben.
silo (en silo probleem) slaat op de typische strakke scheiding in veel IT organisaties tussen systeembeheer, netwerkbeheer, applicatie beheer, database beheer , storage beheer, firewall beheer etc etc.

Als gebruiker/klant (en dus zelfs als interne IT medewerker) blijken dingen dingen die samenwerking van meerdere silo's nodig hebben enorm tijdrovend en lastig te zijn, omdat iedereen binnen de silo alleen naar z'n eigen domeintje kijkt, z'n eigen straatje schoonveegt "ligt niet ons" en alleen maar tickets heen en weer stuurt .

Die stijl van organisatie (en typische probleem ervan) heeft een naam en dat is dus "silo" dan wel "typische silo problemen" .
(denk aan opslag silo's - een rijtje van die grote cilinders naast elkaar die allemaal los staan) .

In dit geval vind ik de term marketing of bullshit bingo niet helemaal terecht - een bepaald veelvoorkomend concept of fenomeen krijgt een naam , dat is overal zo.

Het klinkt alsof iemand een managementboek heeft opgeslagen en de smaak van de maand probeert toe te passen op de praktijk.Sowieso zou ik de artikelen van iemand die 'winzten' belooft niet al te serieus nemen.

Ah, bedoelde je dat. Interessant stukje, daar niet van, maar de vraagsteller had het over eigenschappen van technische systemen, niet over organisatorische problemen die los staan van die techniek.
Het zijn hulpmiddelen om deployment van software op een flexibele manier te kunnen inrichten. Dat het Wikipedia-artikel over Kubernetes het woord "management" in het rijtje doelen opneemt wil niet zeggen dat het organisaties kan beheren en samenwerkingsproblemen tussen verschillende groepen mensen pretendeert op te lossen. Het slaat op het bestieren van containers, een isolatiemechanisme voor processen op computers, niet op organisaties. Jouw interpretatie dat het beweert een oplossing te bieden op dat niveau is volslagen onzinnig. Geen wonder dat niemand snapte wat je met "silo's" bedoelde.

Als je niet weet waarvoor het management en architecten denken dat het een oplossing is blijf je met de waarom vragen in de techniek zitten. Ergerlijker je verwordt zelf tot een knoppen drukkende robot omdat iets zo hoort.

De reden dat management en architecten zo graag docker willen is omdat ze verteld is dat het probleem van softwarebeheer daarmee opgelost zou zijn. https://www.zdnet.com/article/what-is-docker-and-why-is-it-so-darn-popular/
Hier zit het kosten argument: "In a nutshell, here's what Docker can do for you: It can get more applications running on the same hardware than other technologies; it makes it easy for developers to quickly create ready-to-run containered applications; and it makes managing and deploying applications much easier. "

Zoals je al aangeeft zal het het samenwerkingsproblemen tussen verschillende groepen mensen niet oplossen. Vandaar dat herhalende gebeuren. Wat nog ontbreekt is dat er staat dat het gaat om uitrollen van software. Dan komt het woord applicaties en je krijgt wel degelijk het idee naar het management dat het om het samenwerkingsproblemen tussen verschillende groepen zou gaan. De volgende CIO naar de mislukking gaat in de herhaling.

@stoorzender karma4: In het leger willen ze juist https://en.wikipedia.org/wiki/Compartmentalization_(information_security) en dus juist wel Silo's.

Ze doen bij defensie veel moeite om alle informatie te scheiden en af te schermen voor onbevoegden/hackers.

Het liefst heb je al je apparatuur dubbel met een airgap ertussen. Ook in de rechtspraak hebben ze gescheiden netten, maar ik weet niet of die scheiding ook fysiek is. Dat is namelijk duurder en onze rechtspraak zit nogal krap bij kas.

@stoorzender anoniem.
Ook in het leger met silo's naar bepaalde functionaliteit ga je het niet redden door te docker kubernets VM te gaan roepen.
Juist daar is data classificatie met een risico analyse het startpunt. Je gaat niet in een duur automatische wapen meerdere functies op één fysiek apparaat combineren omdat het dan goedkoper zou kunnen.

Voor de rechtspraak https://dewinter.com/2019/08/02/een-inkijkje-in-een-falend-it-project/ (falend in MFA) mist duidelijk wat in de basis bij de ICT daar. Faalt zelfs juridisch.
Het speer project vereiste juist samenwerking zonder die silo's. https://www.logistiek.nl/supply-chain/nieuws/2015/05/defensie-stopt-met-miljoenen-verslindend-speer-project-101133769

Waar ik het over heb is dat je met docker kubernetes VM je containerisatie silo's op de verkeerde plak opbouwt.
Beveiliging informatieveiligheid continuïteit beschikbaarheid (BIV BIR BIO) is geen technisch ICT feestje.
Het zijn bedrijfs- organisatie eisen en doelen, daar gaat de samenwerking ICT en organisatie nu net mank. Leuk als je wat wilt hobbyen, maar het zou eens echt tijd worden voor serieus ICT als kernactiviteit met de organisatie te doen.

En daarom is het ook mislukt. Q.E.D.

Opzettelijk omdat hetgeen overgenomen werd als ict project wel werkte bij de oosterburen.
Tegenwerking vanuit of organisaties of vanuit de techniek de nerds is gewoonlijk de werkelijke oorzaak dat het niet goed gaat..
Het is dan makkelijker naar een derde te wijzen "de techniek". Inderdaad he hele verhaal al Q.E.D.

Ach, je bent gewoon gereïncarneerd in het verkeerde lichaam!

In Duitsland luisteren de IT Nerds wel naar hun leidinggevende. En zitten ze niet de hele tijd met Linux te kloten in plaats van hun werk te doen.

Duitsland is ook een serieus land. Ze hadden 20 jaar geleden al een eigen Linux distributie (SuSE) en de hobbyisten daar liepen altijd al vooruit (vooral in de grote getalen) op Nederland. Daarom zijn ook in elke stad hackerspaces en dat al tientallen jaren. Die spaces in Nederland zijn afgekomen met de komst van het internet in 1995 , de nieuwe hackerspaces zijn wat popi-jopie makerbot scenes. Duitsers hoeven niet veel te klooien, ze hebben hun basiskennis onder de knie.

Plus ze zijn heel goed met het time commando in de shell. Ik zou zelf geen Duitser kunnen worden tenzij mijn slechte slaap (teveel electronica?) zich betert. Tot die tijd lever ik hier nuttig commentaar op deze site, Duitse humor heb ik nl. wel.

En reincarnatie is onzin. Dat soort afterlife onzin vertellen ze de jihadisten ook.

Hehe. Ik heb daar twee-en-een-half-jaar gewerkt als ITer, we hadden een half-dozijn niet-windows OSen in gebruik (linux, in de vorm van verschillende distributies, was er maar een van), en ik had op een gegeven moment helemaal geen leidinggevende meer. Ook in "Duitsland" gebeuren wel eens rare dingen.

Maargoed, je hoeft niet onder het mes om naar Duitsland te verhuizen en te proberen daar een baantje te krijgen.

Wat het eerste betreft, dat is mogelijk maar daar valt niets aan te veranderen of valt het mij persoonlijk te verwijten.

Het tweede, het zal de Nederlandse cultuur wel zijn, zoals:
https://fd.nl/economie-politiek/1313778/amsterdamse-afvalverwerker-in-greep-van-anarchie dan wel
https://www.ibm.com/developerworks/library/a-devops9/index.html
https://devops.com/devops-the-ultimate-way-to-break-down-silos/

Echter... https://techbeacon.com/app-dev-testing/3-ways-silos-sneak-agile-teams-how-tear-them-down
Ik heb nog nooit opgevangen dat zelfsturende teams aan een lopende band van een product in staat zijn een compleet nieuw product te ontwerpen. Ook bij Toyota is dat met kanban en lean six sigma nooit waargenomen.

Nee ook in duitsland luisteren it-nerds niet naar hun leidinggevende en niet naar wat de gebruikers nodig hebben.
Het tegenbewijs van een algemene uitspraak kan met één tegenvoorbeeld. limux lhm munchen.

Dus karma is onzin?


Sorry! Ik bedoelde mijn opmerking meer gender neutraal. Dus ook van Nederlander (M/V) naar Duitser (M/V)


Hee! Programmeren is een vak. Dat ook op Universiteiten gedoceerd wordt. En veel wiskunde. Dat ook..
Wel eens van programmacorrectheidsbewijzen gehoord? Daar zijn hele dikke boeken over geschreven. En zonder werkervaring aan de lopende band als een voorvereiste.

Nee, verkondigt onzin.

Het was ooit de basis voor ICT. Edsger Dijkstra als belangrijkste naam en invloedrijkste persoon. Zijn gelijk werd en wordt constant bewezen door de vele zaken die in de praktijk misgaan.

Volgens mij is het al lang weggevallen. Want:
- Uni maastricht gehackt en ze wisten niet hoe dat kon gebeuren en moesten herstellen.
- Radboud stelt tentamens uit want weten niet hoe je een externe DDOS van interne services moet scheiden.

Tegenwoordig heet het werken in zelfsturende scrumteams softwarengineering, Geen idee wat er aan kwaliteit is dan wel geleverd moet worden als er maar wat vinkjes gezet zijn aan het eind van een paar weken.
Vanuit de overheid en elders wordt het beeld geschapen dat programmeren is iets als basisschool kennis met wat regeltjes kloppen dan wel wat beeldje slepen. Als je dat niet gezien hebt zit je niet echt in de ICT.

Als de vraag is wat is veiliger Docker of VM dan heb je niet door dat die vraag niet om de gevoelige gegevens gaat war je je zorgen over moet maken. maar over techniek. Mangers kiezen graag voor de goedkoopste oplossing en iets wat herkenbaar is omdat iedereen het doet.

Stel de vraag opnieuw maar zet nu die gevoelige gegevens eens centraal.
Als het resultaat van doosjes benadering is dat je veel kopieen van die gegevens van en naar die doosjes moet brengen dan introduceer je door het maken van die vele kopieen een onveiligheid door minder controle en een groter kwetsbaar oppervlak.

Ho, ho, dat M/V is tegenwoordig onvoldoende politiek correct! Je schijnt M/V/H (Man/Vrouw/Het) of M/V/D (Man/Vrouw/Ding) te moeten zeggen. Dat is ook meteen handig als er straks KI's bijkomen (nee, nee, geen Kunstmatige Inseminatie! Kunstmatige Intelligentie).