BigGrid virtualisatie/notulen 20090818

From BioAssist
Jump to: navigation, search

Agenda

  1. Notulen van de vorige keer
  2. Presentaties over scenarios
    1. Class 2 scenario - Sander (5 minuten)
    2. Class 3 scenario, user-requirements en bestaande software - Pieter (20 minuten)
  3. Security, risk en manageability - Ronald (20 minuten)
  4. Bespreken doelen en grenzen van dit project

Notulen

Datum 18 augustus 2009

Aanwezig Marc (MvD), Pieter (PvB), Ron (RT), Ronald (RS), Sander (SK), Sven (SG)

Notulen van de vorige keer

Er is geen commentaar op de notulen van de vorige keer. SK geeft aan dat het zijn voorkeur heeft om commentaar op de notulen ruim voor de volgende vergadering per email te ontvangen.

Inleiding

SK leidt de vergadering in. Zijn doel is om de vergadering te eindigen met een plan van aanpak met milestones. Om dat te bereiken wil hij graag de volgende vragen beantwoord zien tijdens de vergadering:

  • Wat moeten VMs kunnen en waarom?
  • Is het nodig om VMs te certificeren?
    • Zo ja, wat zijn de criteria in grote lijnen?

Class 2 scenario

In de presentatie van SK over Class 2 VMs komen de volgende twee Use Cases naar voren:

  1. Een gebruiker wil een analyse voorbereiden op een lokale machine (desktop/laptop). Daarna wil hij/zij de volledige analyse in de zelfde omgeving draaien op het grid.
  2. Een VO wil een grootschalige MC productie draaien. Daarvoor worden resources van verschillende sites gecombineerd in een overlay network door middel van een pilot job framework.

RS geeft aan dat de netwerk omgeving op de desktop/laptop anders kan zijn dan de netwerk configuratie op de grid site. Dus zelfs als een VM goed werkt op de lokale machine, wil dat niet zeggen dat de VM ook goed werkt op de grid site. SK geeft aan dat interactieve toegang tot de VM het debuggen van een dergelijk probleem zou vereenvoudigen, maar het is geen strikte requirement. RT geeft aan dat de netwerk configuratie op een grid site ook de interactieve toegang zou kunnen beperken, netwerk configuratie is een site policy.

SK legt uit dat beide Use Cases voldoende hebben aan een Class 2 VM. Nieuwe Class 2 VMs zullen ongeveer iedere 3 tot 6 maanden worden gereleased, in de tussentijd worden alleen security updates en application patches uitgevoerd. Dit lijkt geen probleem te zijn voor eventuele certificering. In de analyse Use Case zal een gebruiker de VM in user space willen aanpassen en die aanpassingen willen bewaren. RS stelt voor om die wijzigingen te bewaren op een aparte disk die aan de VM kan worden gekoppeld. SK geeft aan dat er nog heel veel werk moet worden verricht voordat er een proof-of-concept omgeving is waarin deze Use Cases kunnen worden getest.

Class 3 scenario, user-requirements en bestaande software

In de presentatie van PvB over Class 3 VMs presenteert hij zijn lange termijn visie op Big Grid. Daarin leveren Big Grid sites de hardware (storage & compute), waar zich onder andere de VM images bevinden. Verder zijn er een aantal gedistribueerde services, zoals voor het bouwen en onderhouden van de VMs. Accounting is de primaire centrale verantwoordelijkheid van Big Grid in deze visie. Hij presenteert een nieuwe middleware stack met een Virtual Machine request queue, Identity Provision en VOMS services. De huidige gLite middleware stack is alleen nog aanwezig als legacy. De nieuwe stack zal door middel van Virtualisatie/Emulatie in staat zijn om een grote diversiteit aan distributies, software, applicaties en hardware platforms te ondersteunen, die door de gebruikers kunnen worden aangeboden. PvB stelt dat ook legacy HEP applicaties op die manier zullen worden ondersteund.

Er ontstaat een discussie over de rol van Big Grid. SK vraagt wat de activiteiten van Big Grid zijn in de door PvB geschetste visie. PvB antwoord dat die activiteiten bestaan uit de accounting, het verzorgen van de interfacing tussen services en sites en het documenteren van procedures etc. Big Grid is bijvoorbeeld verantwoordelijk voor de ondersteuning van andere middleware stacks. MvD zegt dat daar mogelijk ruimte voor is.

PvB vervolgt zijn presentatie. Een eerste stap in de goede richting kan worden gezet door de gebruikers de mogelijkheid te bieden om VMs te genereren van standaard templates, die ze daarna naar wens kunnen aanpassen en draaien. MvD en PvB geven aan dat een significant deel van de gebruikers kan werken met standaard templates, mits nieuwe templates kunnen worden aangevraagd en die templates door de gebruiker kunnen worden aangepast. Er is ook een significant deel van de gebruikers dat niet voldoende heeft aan een template en een volledig "customized" VM nodig heeft. Het is lastig om te schatten hoe de gebruikers zijn verdeeld (percentages) over deze twee groepen.

De discussie over de rol van Big Grid komt nog even terug. SK vraagt of men een rol ziet voor Big Grid in de ontwikkeling van VM templates voor gebruikers, bijvoorbeeld door de Application Domain Analysists. MvD en PvB denken dat deze rol niet groot zal zijn. SK en RS merken op dat volgens hun een belangrijk deel van de toegevoegde waarde van Big Grid is terug te vinden in de application support van de application domain analists aan de gebruikers, zodat ze effectief gebruik kunnen maken van de e-science infrastructuur. Als voorbeeld vraagt SK hoe de toegang tot Big Grid services vanuit de VMs zal plaatsvinden, als deze VMs niet standaard gebruik maken van de grid security infrastructure. MvD geeft aan dat daarvoor gebruik kan worden gemaakt van tools zoals ToPoS.

Security, risk en manageability

In de presentatie van RS gaat hij in op policy en security issues voor Class 2 en Class 3 VMs. Hij herhaald zijn standpunt dat Big Grid een toegevoegde waarde heeft ten opzichte van Amazon. Operations is er voor verantwoordelijk dat de toegankelijkheid van services, de vertrouwelijkheid, privacy en integriteit van de data en de directe koppeling van gebruikersacties aan een individu wordt gegarandeerd. Hij herhaalt dat de extra software laag die nodig is voor het draaien van alle soorten VMs (Class 1, 2 en 3) extra risico's tot gevolg heeft omdat het aantal vulnerabilities toeneemt. Die risico's moeten tot acceptabel niveau worden teruggebracht. Mogelijke middelen hiervoor zijn het beperken van de netwerk connectiviteit en het gebruik van user accounts in plaats van priviliged accounts in de VM. SG merkt op dat het risico van een ontsnapping uit de VM veel groter wordt bij het ontbreken van een scheiding tussen user en priviliged accounts en/of bij het toestaan van inbound IP. Een ontsnapping uit een VM kan vervolgens relatief eenvoudig worden gebruikt voor het aanvallen van de volledige grid infrastructuur. RS maakt duidelijk dat de scheiding tussen user en priviliged accounts alleen mogelijk is voor Class 2 VMs en certificering noodzakelijk maakt. Hij geeft aan dat certificatie een aanzienlijk inspanning vereist en dat het niet duidelijk is wie die inspanning zou moeten gaan leveren. MvD vraagt of de scheiding tussen user en priviliged accounts het enige significante verschil tussen Class 2 en Class 3 VMs is. SK bevestigt dat het daar in de praktijk op neer komt.

In het vervolg van zijn presentatie besteedt RS aandacht aan de beheersbaarheid van Class 2/3 VMs. De boodschap is dat het opvolgen van een incident een enorme inspanning vereist en zeer ernstige gevolgen kan hebben voor de beschikbaarheid van Big Grid resources voor een VO, of bij kruisbestuiving zelfs voor meerdere VOs, tijdens een lopend onderzoek. Hij verklaart dat het opvolgen van incidenten vele malen duurder is dan het certificeren van VMs. Het verschil tussen Big Grid en Amazon kan volgens RS worden herleid naar de geavanceerde en zeer kostbare (software) infrastructuur die Amazon gebruikt, waardoor priviliged accounts in de VM op Amazon beheersbaar blijven. Verder wijst hij op de grote hoeveelheid personeel die bij Amazon beschikbaar is op 24x7 basis. Ook zijn de gevolgen van een incident voor de reputatie van Amazon minder schadelijk dan voor de reputatie van Big Grid.

Er volgt een discussie over de gevolgen van reputatieschade voor Big Grid en de Big Grid partners. Hoewel niet iedereen het eens is over de exacte gevolgen van deze schade, wordt wel door alle aanwezigen aangegeven dat reputatieschade een onwenselijke situatie is.

In het laatste deel van zijn presentatie gaat RS in op de VO Box policy. Deze policy zou vergelijkbaar kunnen zijn met die voor VMs. Een VO Box draait software van de VO in user space. Er zijn twee soorten. Het eerste soort heeft geen priviliges in het trusted network. Dit is de oplossing die ook in de toekomst zal worden ondersteund. Het tweede soort heeft wel priviliges in het trusted network maar deze oplossing moet in de toekomst worden uitgefaseerd. PvB geeft aan dat hij een heel andere policy wil zien voor VMs. Als voorbeeld gebruikt hij de policy die wordt gebruikt voor het Nikhef draadloos netwerk. Dit netwerk geeft toegang tot internet en verder niets, gebruikers mogen dan draaien wat ze willen in een gedemilitariseerde zone (DMZ). Het is voor PvB niet duidelijk wat de risico's zijn van een Class 3 VM die in een dergelijke 'black box' omgeving draait.

RS heeft feedback gevraagd van Big Grid Operations Steering Team (OST) over het gebruik van Class 2/3 VMs op Big Grid resources. Het huidige standpunt van OST is dat er geen ondersteuning komt voor het draaien van Class 3 VMs op Big Grid. RS en RT geven aan dat er naar hun mening verschillende obstakels zijn voor het gebruik van het grid, of in het algemeen bij iedere opschaling in resources. Ten eerste wordt de authenticatie ingewikkelder, ten tweede verandert de user interface en ten derde verandert de omgeving. Het is voor hun niet duidelijk dat het minimaliseren van een van de drie obstakels (de omgeving) leidt tot een drastische toename van de interesse voor het grid. MvD en PvB vinden dat alle 3 de obstakels moeten worden aangepakt.

Bespreken doelen en grenzen van dit project

In het laatste deel van de vergadering wordt geprobeerd een antwoord te vinden op de vragen die in het begin zijn voorgelegd. RS kon hier helaas niet bij aanwezig zijn en zal eventueel per email reageren.

  • Wat moeten VMs kunnen en waarom?
  • Is het nodig om VMs te certificeren?

SK geeft aan dat er een onoverbrugbare kloof lijkt te zijn tussen het statement van OST ("geen ondersteuning voor Class 3 VMs") en het statement van de vertegenwoordigers van de niet-HEP applicaties uit de voorgaande vergadering ("alleen Class 3 VMs zijn interessant"). Er moet een compromis worden gevonden. MvD stelt als compromis voor om niet de VMs maar de procedure voor het maken van de VMs te certificeren. De gebruikers kunnen dan, bijvoorbeeld via een webinterface, hun eigen VM samenstellen uit een gecertificeerde package repository. Aan de repository kunnen de verschillende packages en versies worden toegevoegd die de gebruikers nodig kunnen hebben. De VM die zo wordt samengesteld, kan daarna alleen nog in user space worden aangepast. SK reageert positief, deze oplossing is waarschijnlijk acceptabel voor OST. PvB heeft zijn bedenkingen, hij wil het Class 3 scenario verder uitwerken en uitzoeken of er mogelijkheden zijn om OST te overtuigen van de haalbaarheid. SK geeft aan dat hij ernstig twijfelt aan de realisatie van de Class 3 oplossing binnen de voor de werkgroep gestelde termijn. SG stelt dat veel van de werkzaamheden voor Class 2 en Class 3 VMs hetzelfde zijn en dus nu al in parallel kunnen worden gestart.

RS geeft via email aan dat het compromis van MvD waarschijnlijk geen fundamentele problemen voor het OST oplevert. Wel plaatst hij een aantal opmerkingen, die kunnen worden meegenomen in de requirements bij de ontwikkeling van het package repository:

  • Er moet een voorziening zijn om specifieke versies van packages weg te halen uit het repository. Het kan altijd gebeuren dat bijvoorbeeld een kritische kernel exploit wordt ontdekt die ook aanwezig is in een kernel in ons repository.
  • Er moet een faciliteit zijn om een image dat eerder gegenereerd is, alleen nog toe te staan na aanpassing van de packages waarin de exploit is gevonden. Het is waarschijnlijk niet triviaal om dit te realiseren, maar dient wel mee te worden genomen in de requirements.

Besloten wordt om twee trajecten te starten. Ten eerste gaat MvD in samenwerking met PvB een voorstel uitwerken voor het systeem met de gecertificeerde package repository. In de volgende vergadering zal dat voorstel worden gepresenteerd. Ten tweede zal PvB onderzoeken of de door RS gepresenteerde problemen met Class 3 VMs kunnen worden opgelost op een manier die voor het OST acceptabel is. Hij zal de resultaten presenteren als hij voldoende vorderingen heeft gemaakt met dit onderzoek, mogelijk al in de volgende vergadering.

Via email biedt RS aan om buiten de vergaderingen om mee te denken met PvB over een alternatief voorstel voor Class 3 VMs.

Naast deze twee trajecten zal SK met RT en RS een ontwerp gaan maken voor de achterliggende infrastructuur voor VMs. Daarbij moeten de verschillende VM technologieën en beschikbare tools worden bestudeerd. Het is cruciaal dat deze infrastructuur geschikt is voor het draaien van zowel Class 2 als Class 3 VMs, zodat het gebruik van Class 3 VMs technisch mogelijk is.

Als laatste verzoekt MvD aan SK en PvB om de volgende vergadering met concrete Use Cases te komen, met de namen van mensen (bij voorkeur mensen buiten de werkgroep) die ze gaan uitvoeren. Deze Use Cases kunnen dan als proof-of-concept worden geïmplementeerd.

Actielijst

  1. Uitwerken van het voorstel voor een systeem dat VMs kan bouwen uit een gecertificeerde package repository. (MvD in samenwerking met PvB)
  2. Onderzoeken of de door RS gepresenteerde problemen met Class 3 VMs kunnen worden opgelost op een manier die voor het OST acceptabel is. (PvB)
  3. Ontwerp maken voor de achterliggende infrastructuur voor het beheer van VMs. (SK, RS en RT)
  4. Aanleveren van concrete Use Cases met de namen van mensen die ze gaan uitvoeren. (SK en PvB)

Volgende vergadering

Donderdag 3 september 12:30