Az OpenStack Neutron egy rugalmas és skálázható hálózati szolgáltatás, amely lehetővé teszi a felhasználók számára, hogy különböző típusú hálózatokat hozzanak létre és kezeljenek. A Neutron több hálózati típust támogat, amelyek különböző felhasználási esetekre és telepítési forgatókönyvekre szolgálnak. Az egyes hálózati típusok saját jellemzőkkel rendelkeznek, és kiválasztásuk szoros összefüggésben áll a környezet méretével, a biztonsági követelményekkel és a skálázási elvárásokkal.

A legegyszerűbb típus a flat network, amelynél minden példány (instance) ugyanahhoz az egyetlen, nem szegmentált hálózathoz csatlakozik. Ez egy közös broadcast domain, amely nem nyújt semmilyen izolációt vagy szeparációt. Ilyen hálózatokat általában kisebb környezetekben vagy menedzsment célokra használnak, ahol a biztonsági szétválasztás nem követelmény. Több-bérlős (multi-tenant) infrastruktúrákban azonban ez a megközelítés nem alkalmazható, mivel teljes mértékben hiányzik belőle az elszigetelés.

A VLAN (Virtual LAN) már lehetővé teszi a forgalom szegmentálását az IEEE 802.1Q szabvány szerinti címkézéssel. Minden VLAN-hoz egyedi azonosító (VLAN ID) tartozik, amely alapján elkülöníthető a különböző bérlők forgalma ugyanazon fizikai hálózaton belül. Ez megfelelő megoldás azoknak a szervezeteknek, amelyeknek szükségük van a hálózati izolációra, ugyanakkor korlátozást jelenthet a VLAN ID-k száma (maximum 4096), ami nagy méretű környezetekben szűk keresztmetszetet jelenthet.

A VXLAN (Virtual Extensible LAN) jelentős előrelépést biztosít ebben a tekintetben. Egy UDP-alapú alagút technológiáról van szó, amely Layer 2 kereteket képes becsomagolni, lehetővé téve a hálózati szegmentációt milliós nagyságrendben (akár 16 millió különálló szegmens). A VXLAN különösen alkalmas nagy léptékű, több-bérlős rendszerekhez, ahol a VLAN ID-k száma már nem elegendő. Támogatja a rugalmas topológiák kialakítását, beleértve a fizikai határokon átnyúló hálózatokat is. Mindez viszont bizonyos mértékű feldolgozási többletet és adott esetben specifikus hardver- vagy szoftvertámogatást igényel.

A GRE (Generic Routing Encapsulation) egy másik alagúttechnológia, amely egyszerűbb és célzottabb felhasználási esetekre alkalmas. GRE elsősorban point-to-point kapcsolatok kialakítására használható, például VPN-ekkel együttműködve. Bár nem nyújt akkora rugalmasságot vagy skálázhatóságot, mint a VXLAN, mégis hasznos lehet kevésbé komplex környezetekben.

A GitforGits példaszervezet jelenlegi topológiája szegmentált hálózatokat használ különböző részlegek – fejlesztés, tesztelés, éles üzem – számára. A biztonságos hálózati izoláció alapvető követelmény számukra, ugyanakkor a rendszer egyszerűsége és kezelhetősége is fontos szempont. Jelenleg a szervezet VLAN-típusú hálózatokat és flat hálózatokat is használ. A VLAN a mostani infrastruktúra számára megfelelő választás, de a bővíthetőség érdekében hosszú távon érdemes áttérni VXLAN-alapú topológiára.

A Neutron konfigurálása ennek érdekében a következő lépésekből áll. Először a VXLAN támogatást kell engedélyezni az ML2 plugin konfigurációs fájljában. A type_drivers és tenant_network_types értékeit vxlan-ra kell állítani, továbbá meg kell adni a használható VNI (VXLAN Network Identifier) tartományt. A Layer 2 ügynök (például Open vSwitch) konfigurációjában biztosítani kell, hogy a helyi IP-cím és a tunnel típus szintén vxlan legyen. A változtatások érvényesítéséhez újra kell indítani a Neutron szolgáltatásokat.

A konfiguráció helyességének ellenőrzése céljából létrehozható egy teszthálózat az openstack network create paranccsal, majd a network list --long parancs kimenetéből ellenőrizhető, hogy a megfelelő szegmentációs típus valóban VXLAN-e.

A hálózati típusok ismerete nemcsak az architektúra megtervezésében, hanem a hibaelhárításban is alapvető fontosságú. Fontos megérteni, hogy a különböző típusok milyen elvárásokat támasztanak a fizikai infrastruktúrával szemben – például, hogy a VXLAN megfelelő működéséhez szükséges lehet az MTU érték növelése vagy az UDP portok engedélyezése a tűzfalakon. Emellett a hálózatok közötti forgalomirányítás (L3 routing), a security group szabályok, a floating IP-k konfigurációja, valamint a Neutron és az SDN-kontrollerek integrációja is jelentős szerepet játszik egy biztonságos, rugalmas és robusztus OpenStack-alapú felhőinfrastruktúra kialakításában.

A felhasználónak továbbá tisztában kell lennie azzal, hogy a Neutron csak a kontroll réteget biztosítja – a tényleges hálózati viselkedést az alatta futó fizikai és virtuális infrastruktúra implementálja. Ezért minden konfigurációs lépésnél kulcsfontosságú a konzisztencia biztosítása az OpenStack és a hálózati hardver/szoftver között. A hibakeresés során érdemes minden szinten (Neutron API, ügynökök, OVS, fizikai kapcsolók) ellenőrizni a forgalom útját, mert egyetlen hibás paraméter vagy inkompatibilitás az egész kommunikációt megbéníthatja.

Hogyan biztosítja az SSH kulcs injektálás a biztonságos és automatizált példánytelepítést a felhőben?

Az SSH kulcsalapú hitelesítés alapvető biztonsági gyakorlat a felhőkörnyezetben történő példánytelepítés során. Az SSH (Secure Shell) kulcsok használata jelszavak helyett nem csupán erősebb védelmet nyújt, hanem elősegíti az automatizált hozzáférést is, amely nélkülözhetetlen a dinamikusan változó infrastruktúrákban. Az SSH kulcspár két részből áll: egy nyilvános és egy privát kulcsból. A nyilvános kulcsot a példány létrehozásakor injektáljuk a rendszerbe, míg a privát kulcsot kizárólag a felhasználó birtokolja, és az nem kerülhet hálózatra.

A hitelesítés ezen formája megkerüli a jelszavak gyengeségeit. A privát kulcs sosem hagyja el a felhasználó gépét, így annak kompromittálása kizárólag helyi szinten lehetséges. Egy jól kezelt kulcspár esetén brute-force támadások gyakorlatilag kizártak, különösen akkor, ha 4096 bites RSA vagy Ed25519 algoritmusokat használunk. A DSA vagy rövidebb kulcsok már nem ajánlottak. A felhasználó kényelmesen, jelszómegadás nélkül tud belépni példányaiba, ami nemcsak időt takarít meg, hanem lehetővé teszi a szkriptek és eszközök automatizált hozzáférését is.

OpenStack környezetben a kulcsok központi kezelése is lehetséges, ami elősegíti a hozzáférési jogosultságok gyors és hatékony kezelését. Az adminisztrátorok könnyedén frissíthetik vagy visszavonhatják a kulcsokat, így a hozzáférések dinamikus változtatása egyszerűen megvalósítható. A kulcsok listázása, törlése és cseréje egyértelmű parancsokkal végezhető, a példányokat pedig bármikor újraindíthatjuk más kulccsal, ha a biztonság úgy kívánja.

Az SSH kulcs injektálás folyamata egy új kulcspár létrehozásával kezdődik. Például a ssh-keygen -t rsa -b 4096 -C "gitforgits-key" paranccsal generált kulcs automatikusan a felhasználó .ssh könyvtárába kerül. A nyilvános kulcsot ezután az OpenStack rendszerbe töltjük fel a openstack keypair create --public-key paranccsal. Ezzel a kulcs már készen áll arra, hogy példányindításkor használatba vegyük. A Nova komponens segítségével a openstack server create parancsban megadhatjuk a --key-name opcióval, hogy mely kulcsot használja a rendszer a példány eléréséhez.

A példány elindítása után a openstack server list paranccsal ellenőrizhetjük annak állapotát. Amint a státusz "ACTIVE"-re vált, a példány készen áll a használatra. Az SSH hozzáférés a ssh -i ~/.ssh/gitforgits-key ubuntu@<IP-cím> paranccsal történik. Amennyiben a kulcspár érvényes és az IP-cím helyesen lett lekérdezve, a kapcsolat létrejön, és a felhasználó beléphet a rendszerbe jelszó megadása nélkül.

A rendszeres kulcsrotáció, a kulcsok célhoz kötött használata (felhasználó, példány, projekt szerint) és a nem használt kulcsok eltávolítása alapvető biztonsági gyakorlatok. A kulcsok auditálása — vagyis annak nyomon követése, hogy melyik kulcs hol van használatban és kik férnek hozzá — szintén elengedhetetlen, különösen olyan környezetekben, ahol sok felhasználó és sok példány van jelen.

Fontos felismerni, hogy az SSH kulcsmenedzsment nem csupán technikai kérdés, hanem biztonságpolitikai tényező is. Egyetlen kompromittált kulcs az egész infrastruktúrát veszélybe sodorhat, ha nincs szegmentált hozzáférés. Ebből következik, hogy a biztonság nem csak a kulcs e