Kihagyás

11

8. Modul: Virtuális Hálózatok (Azure VNet)

Amikor felhős erőforrásokat hozunk létre (mint az SQL adatbázisod), azok alapértelmezés szerint kapnak egy publikus IP-címet. Bár jelszó védi őket, a nagyvállalati biztonság ezt nem engedi: a cél az, hogy a szerverek "láthatatlanok" legyenek az internet felől, és csak egy zárt, privát hálózaton belül kommunikálhassanak egymással.

Ezt a zárt burkot hívjuk Virtual Networknek (VNet).

Készítsünk egy saját hálózatot, és nézzük meg, hogyan tudnánk "bezárni" mögé az adatbázisunkat! A VNet létrehozása teljesen ingyenes.

1. lépés: A VNet létrehozása

  1. Az Azure Portal felső keresőjébe írd be: Virtual networks, és kattints rá.
  2. Kattints a + Create gombra.
  3. A Basics fülön:
  4. Resource group: Válaszd a megszokott rg-azure-training-et.
  5. Virtual network name: Legyen vnet-training.
  6. Region: Válaszd ugyanazt a régiót, ahol az SQL adatbázisod van.
  7. Kattints az Addresses (IP-címek) fülre felül.
  8. Itt látod a hálózat "tervrajzát". Az Azure alapból létrehoz egy nagy címtartományt (pl. 10.0.0.0/16) és benne egy default (alapértelmezett) alhálózatot (Subnet). Ezt most hagyhatjuk így, ez tökéletes lesz.
  9. Kattints a Review + create, majd a Create gombra.

2. lépés: Az SQL adatbázis "bezárása" a VNetbe (Service Endpoint)

Most megmondjuk az SQL szervernek, hogy ezentúl fogadjon el forgalmat ebből a privát hálózatból.

  1. Ha a VNet létrejött, menj vissza a kezdőképernyőre, és keresd meg az SQL szerveredet (ne az adatbázist, hanem a szervert, aminek a neve sql-...).
  2. A bal oldali menüben kattints a Networking menüpontra.
  3. Középen látni fogsz egy olyan részt, hogy Virtual networks. Kattints a + Add a virtual network rule (Virtuális hálózati szabály hozzáadása) linkre.
  4. A felugró ablakban:
  5. Rule name: vnet-szabaly
  6. Subscription: A te előfizetésed.
  7. Virtual network: Válaszd ki a frissen létrehozott vnet-training-et.
  8. Subnet: Válaszd a default alhálózatot.
  9. Kattints az OK gombra. (Itt a háttérben az Azure bekapcsol egy úgynevezett Service Endpoint-ot. Ez egy láthatatlan cső a VNeted és az SQL szerver között).
  10. A bal felső sarokban ne felejts el a Save (Mentés) gombra kattintani!

Mit értünk el ezzel? Ha most lenne egy virtuális gépünk vagy egy Kubernetes clusterünk ezen a vnet-training hálózaton belül, akkor a publikus internet érintése nélkül, az Azure privát gerinchálózatán keresztül, villámgyorsan és maximális biztonságban tudna kapcsolódni az adatbázishoz. Nagyvállalati környezetben ez a standard felállás: a "Public access" (Nyilvános hozzáférés) fülön mindent letiltanak, és csak a VNet-en keresztül engedik be a forgalmat.

1. A Checkbox kikapcsolása

Ha az "Allow Azure services and resources to access this server" bekapcsolva marad, az azt jelenti, hogy az Azure-on belülről bárki (még egy másik cég felhős szolgáltatása is) el tud jutni a te SQL szervered bejelentkezési kapujáig (bár a jelszó nélkül nem jut be). Ha viszont kikapcsolod, akkor a publikus kapu teljesen bezárul. Ekkor már csak és kizárólag az általad megadott VNet-ből (vagy a saját IP címedről) lehet egyáltalán "bekopogni" a szerverhez.

2. Hogyan kerül a Kubernetes (AKS) ebbe a VNet-be?

Amikor mi létrehoztuk az AKS-t, hagytuk, hogy az Azure csináljon neki egy saját, rejtett hálózatot (ez volt a MC_... resource groupban). Ha VNet-es architektúrát építünk, a következőképpen nézne ki a folyamat:

  1. A hálózat előkészítése: A VNet-edben (vnet-training) létrehozol két alhálózatot (Subnet). Az egyik mondjuk az aks-subnet, a másik a db-subnet.
  2. AKS létrehozása (Saját hálózattal): Amikor az AKS varázslót pörgeted, a Networking (Hálózat) fülön van egy opció: Network configuration. Itt az alapértelmezett Kubenet helyett az Azure CNI-t választod, és szépen kiválasztod a saját vnet-training hálózatodat, azon belül is az aks-subnet-et. Így az összes Kubernetes worker node (gép) ebből a privát hálózatból kap IP-címet.
  3. A kapu kinyitása (amit az előbb csináltunk): Az SQL szervernél hozzáadod a kivételekhez a vnet-training hálózatot.

3. Hogyan csatlakozik a Kód (a Pod)?

Ez a legszebb az egészben: fejlesztőként semmit nem kell átírnod! Az alkalmazásod (pl. a Python vagy C# kódod, ami a K8s Podban fut) pontosan ugyanazt a standard Connection Stringet fogja használni (pl. Server=tcp:sqlserver-[neved].database.windows.net,1433;Database=sqldb-training...).

A varázslat az infrastruktúra szintjén történik: * Amikor a Pod elküldi a lekérdezést az SQL szerver felé, az Azure belső DNS és hálózati rendszere (a Service Endpoint) felismeri, hogy: "Aha, ez a kérés a vnet-training-ből jön!" * Mivel te engedélyezted ezt a VNet-et az SQL tűzfalánál, a forgalmat az Azure a saját privát gerinchálózatán keresztül, villámgyorsan bevezeti az adatbázisba.

Így az alkalmazásod és az adatbázisod tökéletes biztonságban, a külvilágtól elzárva tud beszélgetni egymással.