Toepassing project Virtualisatie

Met deze opgave wordt beoogd om de kennis en vaardigheden die je in de verschillende labo's rond virtualisatie, netwerken, security en Linux verworven hebt, te integreren in een realistisch scenario.

We volgen hiervoor een fictief scenario waarbij jullie als kleine cloud-provider resources aanbieden aan enkele klanten die hun toepassingen in een private cloud willen draaien. Elke klant kan zo zijn eigen virtuele infrastructuur opbouwen, beheren en gebruiken binnen de private cloud die jullie als provider aanbieden.

Proxmox is niet de ideale tool hiervoor. In de praktijk zijn er oplossingen die meer geschikt zijn, denk maar aan de VMWare Aria Suite of Apache Cloudstack of... Maar met onze Proxmox-opstelling is het mogelijk dit principe toch te benaderen.
Zo kunnen verschillende klanten (tenants) bv hun eigen IAAS uitbouwen, identieke, overlappende ip-ranges gebruiken, ... Door gebruik te maken in Proxmox van Zones, Vnets, en/of een extra NAT-laag kan dit mogelijk gemaakt worden. In onderstaand scenario kiezen we echter wel een duidelijk verschillende ip-ranges per tenant.

info

Om dit scenario onmiddellijk een nuttige wending te geven zal elke student apart de nodige virtuele machines/containers opzetten om de eigen Proxmox omgeving te monitoren en via dashboards te visualiseren.

Uitwerking

Het eerste deel van deze opgave moeten jullie nog samen als team uitvoeren. Dit deel is immers het stuk van de opgave waarbij jullie als provider de basisinfrastructuur moeten opzetten die de klanten (tenants) zullen gebruiken.

Om het scenario uit te leggen kan een schema veel verduidelijken.

info

Nietegenstaande we zouden kunnen kiezen voor identieke subnets in beide tenants doen we dat hier niet. Dat betekent dat volgende netwerken moeten gebruikt worden:

• Tenant 1:
  • Web => 192.168.10.0/24
  • Db => 192.168.20.0/24
• Tenant 2:
  • Web => 192.168.30.0/24
  • Db => 192.168.40.0/24

Vereisten als Provider

We lijsten hieronder enkele vereisten op die voor het providergedeelte van belang zijn:

1. Om alle IAAS resources van de verschillende klanten later netjes te kunnen scheiden, voorzie je allereerst 2 verschillende Pools (Resource Pools) in Proxmox, één per tenant.

2. Netwerktechnisch willen we ook het verkeer van de verschillende klanten scheiden. Hiervoor gebruiken we Zones in Proxmox.

   Zones in Proxmox

   Zones in Proxmox zijn niet hetzelfde als bv. VLANs. Zones zijn een logische scheiding binnen Proxmox zelf. Je zal wel moeten aangeven op welke manier je onderliggend de verschillende netwerken (VNets) in die zones wil scheiden. Dit kan bv. op basis van VLANs, VXLAN, QinQ, EVPN,... In dit scenario gebruiken we VXLAN (Overlay) om de resources van verschillende klanten te scheiden binnen Proxmox.

   VXLAN

   • Zoek even op hoe Overlay-netwerken werken (zoals bv. VXLAN).
   • Bekijk specifiek ook wat VTEP'S (virtual tunnel endpoints) zijn en hoe jullie deze in jullie Proxmox-setup kunnen gebruiken.
   • Op welke manier wordt de encapsulatie van vxlan-verkeer gerealiseerd? => Houdt hiermee rekening met de MTU-grootte van de VNets die je aanmaakt. => max. MTU-waarde bij vxlan?
   • Het getunnelde VXLAN-verkeer moet over een aparte VLAN lopen. Kies hiervoor de eerste VLAN uit de range die je kreeg in de adrestabel.
     IP-adressen hiervoor mag je zelf kiezen, maar zorg dat deze zeker niet overlappen met andere ip-ranges in de underlay.
     Deze ip-adressen zullen dan ook onmiddellijk fungeren als VTEPs (Peer Address List bij de zone).
   • Maak nu twee zones aan in Proxmox, één per tenant (dezelfde VTEPs kunnen gebruikt worden).

3. VXLAN VNets

   • Maak voor elke tenant apart de nodige vxlan-VNets aan in Proxmox. Koppel deze VNets aan de juiste zone.
   • Bekijk op het schema welke vni's (Tag in Proxmox) je moet gebruiken voor de verschillende Vnets.

4. Met bovenstaande stappen werden de randvoorwaarden om verschillende klanten op je infrastructuur te laten draaien, gerealiseerd. Nu moeten uiteraard de accounts voor de klanten zelf ook aangemaakt worden.

   • Maak hiervoor in Proxmox twee verschillende gebruikersaccounts (student => voornaam.familienaam) aan, één per tenant.
   • Ken deze gebruikers de juiste rollen en permissies toe zodat ze enkel toegang hebben tot hun eigen resources (Pools, Vnets, ...).
   tip

   Je zal even goed moeten nadenken over welke permissies je aan deze gebruikers toekent. Ze moeten immers hun eigen infrastructuur kunnen opzetten en beheren, maar mogen uiteraard niet bij de resources van de andere tenant kunnen.
   Geef ze dus net genoeg rechten om hun job te kunnen doen, maar niet meer dan dat. Denk even na over de rechten op de Resource Pool die je gemaakt had, de Zone, de storage,...
   vb:
   

   Zoals eerder vermeld is Proxmox niet perfect om meerdere tenants te ondersteunen. Maar je zal met bovenstaande stappen toch een voldoende goede scheiding kunnen maken.

5. Als provider voorzie je een centrale router die voor "North-South" communicatie verantwoordelijk is en dus alle verkeer van en naar je datacenter regelt. Deze router maakt gebruik van NAT om alle verkeer van de tenants (alle interne verkeer) naar buiten mogelijk te maken en waar nodig ook extern verkeer van het internet door te geven naar de tenants.

   • Alle uitgaande NAT verkeer, van beide tenants, gaat over het primaire ip-adres naar buiten (het eerste adres van je adres pool in vlan 70 dat nog beschikbaar is).
   • Inkomend verkeer dat van de publieke kant verder zijn weg moet vinden naar de diensten in elke tenant maakt gebruik van secundaire ip-adressen (de volgende ip adressen uit je pool van vlan 70)
   info

   Als Router/Firewall oplossing kunnen jullie de OPNsense applicance installeren. OPNSense is in oorsprong een FreeBSD-gebaseerde open-source firewall en router distributie nauw verwant met pfSense.
   De ISO hiervan kan je downloaden van onze fileserver en op je eigen NFS-share beschikbaar stellen.

Vereisten voor de Tenants

warning

Vanaf hier werkt elke teamgenoot het scenario apart uit. Zorg er voor dat de naamgeving van je resources duidelijk aangeeft van welke tenant ze zijn en plaats deze resources ook in de juiste pools en zones.
Als je stap 4 in het vorige hoofdstukje correct uitgevoerd hebt, zou dit geen probleem mogen zijn. Je kan dan immers elk apart aanmelden met je eigen account (voornaam.familienaam) en werken in je eigen pool/zone.

We lijsten ook hier enkele vereisten op voor het tenantgedeelte:

• Als klant die van de provider een tenant huurt, voorzie je een Firewall/Router (opnieuw een OPNsense) die het verkeer tussen intern en de buitenwereld regelt.

  • Deze router zal ook als DHCP server fungeren voor het netwerk "Web" en "DB".

• Vooraleer je verder gaat met de volgende vereisten, controleer je eerst of alle verkeer vanuit je interne netwerken (192.168.x.0/24) naar de buitenwereld (inclusief internet) correct werkt.

  • Test dit door een VM in het "Web" netwerk op te zetten en te pingen naar een extern adres (bv. 8.8.8.8).

Vereisten Services in de Tenant

Elke tenant (en dus student) zal voorzien in een monitoringoplossing voor de Proxmox-omgeving. Die monitoring moet naar de buitenwereld (=odisee netwerk) bereikbaar gemaakt worden. Als eindresultaat zal je twee dashboards opzetten waarbij je live de load op je Proxmox omgeving kan zien.

Om bovenstaande te realiseren worden vier services gebruikt:

Telegraf:

• Verzamelt data via input plugins en schrijft deze weg via output plugins.
• Input: Proxmox API monitoring (Proxmox VE API en eventueel node metrics)
• Output: InfluxDB

Influxdb:

• Time-series database, gebruikt om alle verzamelde Proxmox metrics op te slaan.
• Kan op dezelfde VM draaien als Telegraf om resources te besparen.

Grafana:

• Visualisatietool voor monitoring.
• Leest data uit InfluxDB en toont dashboards.

Chronograf:

• Alternatieve visualisatietool, specifiek ontwikkeld voor InfluxDB.

toepassing

Telegraph en InfluxDB kunnen best op 1 vm samen geconfigureerd worden om resources te besparen (Telegraf als container).

Voor onze eindgebruikers zijn Grafana en Chronograf extern (via VPN) te bereiken:

• Grafana => grafana_voornaam.teamxx.labci.eu
• Chronograf => chronograf_voornaam.teamxx.labci.eu

info

Beide URN's moeten verwijzen naar hetzelfde ip-adres!!! (uiteraard voor elke student een ander ip-adres).
Op de Provider-router komen de URL's van eenzelfde tenant (student) binnen op een apart ip-adres (secundair ip-adres uit je pool in vlan 70). De provider-router zal dit verkeer dan doorsturen naar de juiste tenant-router (op basis van NAT-regels).
De tenant-router zal dit verkeer dan verder doorsturen naar de juiste Grafana of Chronograf VM/container op basis van de reverse proxy/load balancing regels die je zal opzetten.

OPNsense kan via extra plugins de functionaliteit van een reverse proxy/load balancer aanbieden.
Er zijn verschillende (community-plugins die je kan kiezen zoals os-caddy, os-haproxy, os-nginx,...).
Kies er één uit en gebruik deze om de reverse proxy functionaliteit te realiseren.

in detail wordt dit dus:

Jullie hoeven hiervoor zelf geen DNS-server voor resolving op te zetten. Je kan de benodigde records configureren in een gemeenschappelijk toegankelijke DNS-server. Op deze DNS-server kan je dan de nodige records toevoegen zodat bovenstaande URN's resolven naar een ip-adres op de "publieke" kant van je proxmox-omgeving.

note

Deze ip-adressen zullen uiteraard niet bruikbaar zijn om vanop het publieke internet te surfen naar jullie resources (de ip-adressen uit vlan 70 komen uit een private range). Met jullie VPN (Bij voorkeur Cisco Anyconnect) actief zou dit echter wel moeten werken.

De gegevens van de DNS-server, waar de DNS-zone voor "labci.eu geconfigureerd staat, kan je bereiken via:

• RDP op TBD
• gebruikersnaam: .\labci
• wachtwoord: OdiseeGent!

warning

Gedraag je op deze DNS-service als een 'goeie huisvader'...

Opzetten van de servers in de tenant

Hou bij het opzetten van de servers rekening met de beperkte resources op jullie servers.
Zet Grafana, Telegraf & Chronograf op als containers. Voor influxdb hoef je dat niet te doen, deze service kan je met de package manager installeren. (Grafana en Chronograph elk als een container op een aparte VM)

Om de statusdata uit Proxmox te halen, moet je credentials of een API-token aanmaken. Doe dit volgens de regels van de kunst: Maak een dedicated gebruiker aan in Proxmox (bijv. monitoring@pve). Ken enkel de minimale leesrechten toe die nodig zijn voor API-toegang tot cluster- en VM-metrics. Gebruik bij voorkeur een API-token in plaats van een wachtwoord voor Telegraf.

Reverse proxy - Load Balancer

Zet op de OPNsense van je tenant de reverse proxy/load balancer op zodat zowel grafana_voornaam.teamxx.labci.eu als chronograf_voornaam.teamxx.labci.eu correct doorverwijzen naar de juiste VM/container in je interne netwerk.
Dat werd reeds hierboven al toegelicht.

Beveiliging in de tenant

Beveilig je omgeving.
Deze beveiliging realiseer je niet met de ingebouwde firewall-functionaliteit van het besturingssysteem maar oa. met de Distributed Firewall, een onderdeel van SDN in Proxmox.

De beveiliging van je omgeving realiseer je op twee niveaus:

1. North–South beveiliging (via OPNsense)

   • Gebruik de firewallfunctionaliteit van OPNsense om verkeer tussen het internet en je interne netwerk te controleren.
   • Enkel de reverse proxy mag extern bereikbaar zijn (poorten 80/443).
   • Beperk inkomend verkeer strikt tot het noodzakelijke.

2. East–West beveiliging (via Proxmox SDN – VNet Firewall)
   Proxmox biedt via zijn SDN-module een VNet Firewall, die je kan inzetten om verkeer tussen interne VM’s en containers te regelen.
   Deze firewall werkt distributed over het hele cluster, vergelijkbaar met NSX in vSphere.

Enkele vereisten:

• De InfluxDB-VM mag enkel connecties ontvangen van de Grafana- en Chronograf-containers.
• Toegang tot het interne 192.168.(20,40).0/24 netwerk moet beperkt blijven tot het strikt noodzakelijke.
• Beveilig waar nodig bijkomend, en verantwoord in je verslag waarom je bepaalde poorten of verbindingen toestaat of blokkeert.

Netwerkverkeer in detail

Neem elk individueel met tcpdump (en na download naar Wireshark) in de cli van je proxmox een kijkje naar het netwerkverkeer tussen je verschillende VM's en containers.
Probeer een zicht te krijgen op de verschillende encapsulatie-lagen die boven elkaar gebruikt worden.
Documenteer dit elk individueel met je bevindingen en de nodige screenshots die dit aantonen.