Nul
Virtuele machines (VM) veiliger dan containers? Je denkt misschien dat je het antwoord weet, maar IBM Research heeft gevonden containers kunnen worden als veilig of veiliger, dan vm ‘ s.
James Bottomley, een IBM-Onderzoek Distinguished Engineer top Linux kernel developer, schrijft: “Een van de grootste problemen met het huidige debat over de Container vs Hypervisor beveiliging is dat niemand heeft eigenlijk een manier ontwikkeld om het meten van de veiligheid, dus de discussie is al in kwalitatieve termen (hypervisors ‘voelen’ veiliger dan containers vanwege de interface breedte), maar niemand daadwerkelijk heeft gedaan, is een kwantitatieve vergelijking.” Om te voldoen aan deze behoefte, Bottomley gemaakt Horizontale Aanval Profiel (HAP), ontworpen om te beschrijven beveiliging van het systeem op een manier dat het objectief gemeten kan worden. Bottomley heeft ontdekt dat “de Dokwerker container met een goed ontworpen seccomp-profiel (welke blokken onverwachte system calls) biedt ongeveer gelijkwaardige zekerheid een hypervisor.”
Bottomley begint met het definiëren van Verticale Aanval Profiel (VAP). Dit is alle code, die doorlopen tot het verlenen van een dienst de manier van input naar database-update uitvoeren. Deze code, net als alle programma ‘ s, bevat fouten. De bug dichtheid varieert, maar meer om de code die u dwars door de groter de kans van blootstelling aan een gat in de beveiliging. Stapel gaten in de beveiliging exploits, die zich kan springen in de fysieke server host of VMs-HAPs.
HAPs zijn de ergste vorm van gaten in de beveiliging. Bottomley ze noemt, “potentieel business vernietigen van gebeurtenissen.” Dus, hoe meet je een systeem voor HAPs? Bottomley legt uit:
De Kwantitatieve benadering tot het meten van de HAP zegt dat we de bug dichtheid van de Linux Kernel code en deze vermenigvuldigen met het bedrag van de unieke code doorkruist door het draaiende systeem als na het bereiken van een steady-state (wat betekent dat het niet lijkt te doorkruisen van een nieuwe kernel paden). Omwille van deze methode nemen we aan dat de bug dichtheid uniform te zijn en dus de HAP is benaderd door de hoeveelheid code die doorlopen in de steady state. Het meten van deze voor een draaiend systeem is een heel andere kwestie, maar, gelukkig, de kernel heeft een mechanisme genaamd ftrace die kan worden gebruikt voor het traceren van alle van de functies die zijn genoemd door een bepaalde gebruikersruimte proces en geeft dus een redelijke benadering van het aantal regels code doorlopen. (Let op dit is een benadering omdat we meten het totaal aantal lijnen in de functie zonder rekening te houden met interne code flow, vooral omdat de ftrace-het geeft niet dat er veel details.) Bovendien, deze methode werkt zeer goed voor containers waar alle van de control flow gaat uit van een bekende groep van processen die via het systeem informatie bellen, maar het werkt minder goed voor hypervisors waar, naast de directe hypercall interface, moet je ook toevoegen sporen van de back-end-daemons (zoals de kvm-vhost dat threads in de kernel of dom0 in het geval van Xen).
Kortom, je meet hoe veel regels van de code van een systeem–het blote metaal, VM, of-container: gebruikt voor het uitvoeren van een bepaalde toepassing. De meer-code wordt uitgevoerd, hoe groter de kans is om een HAP-niveau gat in de beveiliging.
Na het definiëren van HAPs en hoe op te meten, Bottomley dan liep een aantal standaard benchmarks — redis-de-bank-set, redis-de-bank-te krijgen, python-tornado en node-express, met de laatste twee ook het uitvoeren van de web-servers met eenvoudige externe transactionele klanten. Hij voerde de tests met Docker, Google gVisor, een container runtime sandbox; gVisor-kvm, dezelfde container zandbak met gebruik van de KVM -, Linux-ingebouwde VM hypervisor; Kata Containers, een open-source lichtgewicht VM; en Nabla, IBM zojuist het type container, die is ontworpen voor sterke isolatie server.
Bottomley gevonden Nabla runtime had een beter “HAP dan de hypervisor opgenomen Kata-technologie, wat betekent dat we hebben bereikt een container systeem met betere HAP (d.w.z. veiliger) dan hypervisors.”
Het was niet alleen de IBM-project, hoewel, dat bleek meer veilig. Ook vond hij, “Docker container met een goed ontworpen seccomp-profiel (welke blokken onverwachte system calls) biedt ongeveer gelijkwaardige zekerheid een hypervisor.”
GVisor was een ander verhaal. In het beste geval, gVisor had de resultaten over, zelfs met Docker gebruiken geval, maar in één geval was het aanzienlijk slechter. Bottomley speculeert dat komt omdat “gVisor probeert te verbeteren insluiting door het herschrijven van de Linux system call interface in te Gaan. Echter, niemand heeft besteed geen aandacht aan het bedrag van het systeem belt het Gaat runtime is eigenlijk gebruiken, dat is wat deze resultaten zijn echt te zien.” Als dat het geval is, Bottomley denkt dat een toekomstige versie van gVisor kan worden herschreven worden veel veiliger.
Het echte punt, hoewel, niet die technologie is meer veilig per se. Het is dat, voor de meest ernstige security problemen, containers en VMs hebben ongeveer hetzelfde niveau van beveiliging. Inderdaad, Bottomley denkt, “het is perfect mogelijk om containers die zijn veiliger dan hypervisors en legt te rusten, ten slotte, de argumenten over de veilige technologie.”
“De volgende stap,” vervolgde hij, “is het vaststellen van de mate van blootstelling aan een schadelijke toepassing is en om dat te doen, een soort van fuzz testen dient te worden gebruikt”
Daarnaast Bottomley werk is slechts het begin. Hij is aangetoond dat het mogelijk is om objectief te meten is, applicatie beveiliging. Zoals hij zei: “ik verwacht niet dat dit zal het laatste woord in het debat, maar door te beschrijven hoe we het deden ik hoop dat anderen kunnen ontwikkelen kwantitatieve metingen.”
Verwante Artikelen:
Kata Containers Project gestart om beveiligde container infrastructureGoogle open bronnen gVisor, namelijk een container runtimeTechRepublic: 5 tips voor het beveiligen van uw Docker containers
Verwante Onderwerpen:
Linux
Beveiliging TV
Data Management
CXO
Datacenters
0