A Microsoft Foundry külön hálózati szabályokkal korlátozza az ügynököket
A Microsoft Foundry útmutatója olyan hálózati kimeneti szabályokat mutat be, amelyekkel a hosztolt ügynökök által elérhető célpontok külön szabályzatban határozhatók meg. A funkció előzetes állapotú, nem általánosan elérhető, és a Microsoft szerint nem használható éles környezetben.
- A hosztolt ügynökök célpontjai külön, felülvizsgálható hálózati szabályzatban adhatók meg.
- A bemutató kezdetben Audit módban figyeli a kimenő hívásokat, az alapértelmezett művelet Deny.
- A szabályzat a RaiConfig beállítással kapcsolható az ügynök verziójához.
- A hálózati határt engedélyezett és szándékosan tiltott próbahívással kell ellenőrizni.
- A funkció előzetes, és a Microsoft szerint nem használható éles környezetben.
A célpontok szabályzata elválik az ügynök kódjától
A Microsoft példája egy számlafeldolgozó ügynököt használ, amely egy beszállítói API-t és egy pénzügyi API-t ér el. A fejlesztőknek ugyanakkor olyan helyzetekkel is számolniuk kell, amikor egy dokumentumban ismeretlen feltöltési hivatkozás jelenik meg, vagy egy új segédkönyvtár előre nem látott URL-t követ. Ilyenkor az egyik fontos kérdés az, hogy a folyamat pontosan hová küldhet hálózati kérést.
A Foundry bemutatója ezt a döntést a hosztolt ügynök definíciójához kapcsolt, külön kezelhető szabályzatba helyezi. Így a célpontokra vonatkozó engedélyek felülvizsgálható objektummá válnak, miközben az alkalmazásnál marad az üzleti logika, valamint az API-k hitelesítése és jogosultságkezelése.
A Microsoft szerint egyetlen HTTP-wrapperbe épített ellenőrzés csak az azon keresztül indított hívásokat védi. A hálózati határ ezért nem az eszközök egyszerű listájával azonos. A bemutató közönséges kimenő HTTP-kérésekkel szemlélteti a különbséget.
Audit módban először megfigyelhető a forgalom
Az útmutatóban a fejlesztő két pontos hosztnevet engedélyez egy új RAI-szabályzatban: egy pénzügyi és egy beszállítói API-t. A teszt feltöltési célpontja nem kerül az engedélyezett listára. A szabályzat alapértelmezett művelete a tiltás, hálózati módja kezdetben Audit.
A konfiguráció a Microsoft.DefaultV2 alapra épül, és a hálózati szabályzatban FQDN-alapú szabályokat használ. A Microsoft azt javasolja, hogy a fejlesztők pontos hosztnevekkel kezdjenek, mert ez a felülvizsgálók számára könnyebben értelmezhető határt ad, mint egy széles helyettesítő karakteres szabály.
A beállítás létrehozásához Azure CLI és olyan identitás szükséges, amely írhat RAI-szabályzatokat az adott fiókban. Az útmutató külön ellenőrző lekérdezést is ad a mentett konfigurációhoz. Ezzel megvizsgálható a szabályzat azonosítója, az Audit mód, az alapértelmezett Deny művelet, valamint a két engedélyezett hosztnév. Ez a lekérdezés a tárolt beállítást igazolja, a futásidejű érvényesítést nem.
A szabályok sorrendben kerülnek kiértékelésre, az első egyezés határozza meg a műveletet. Ha nincs egyezés, az alapértelmezett művelet lép életbe. A Foundry platform által megkövetelt kapcsolatok ettől külön engedélyezettek, ezért a Deny alapértelmezés nem jelenti azt, hogy minden futásidejű kapcsolat blokkolva van.
A szabályzatot a hosztolt ügynök verziójához kell kapcsolni
A Microsoft példakódja a RaiConfig beállítással kapcsolja a szabályzatot az ügynök új verziójához. A bemutató az azure-ai-projects legalább 2.2.0-s verzióját és az azure-identity csomagot használja. A teljes ARM-azonosítót kell megadni, nem pusztán a szabályzat nevét.
A létrehozási példa egy már létező, Responses protokollt megvalósító konténerképre épül. A konténer 1 CPU-t és 2 GiB memóriát kap, a protokoll verziója 2.0.0. A fejlesztőnek ezután a szokásos hosztoltügynök-telepítési és indítási folyamatot kell befejeznie, majd a tesztforgalmat a konkrét verzióra irányítania.
A szabályzat célpontengedélye önmagában nem ad jogosultságot az adott API-hoz. A pénzügyi és beszállítói szolgáltatások hitelesítési adatait, valamint hozzáférési ellenőrzéseit továbbra is az alkalmazásnak kell kezelnie. A Microsoft portálos használatot is említi: ott guardrail hozható létre, Network egress szabályok adhatók hozzá, majd a szabályzat hozzárendelhető a hosztolt ügynökhöz.
A hálózati határt tényleges kérésekkel kell tesztelni
Az útmutató két ártalmatlan próba-URL használatát javasolja. Az egyiknek az engedélyezett pénzügyi hosztnévhez kell tartoznia, a másiknak pedig egy kontrollált, nem platformhoz tartozó, tiltott célpontnak. Mindkét végpontnak 200-as választ kell adnia, és rögzítenie kell a beérkező kéréseket. A tesztben kizárólag szintetikus adatok használhatók.
A próbafüggvény a két címet a futtatási környezet változóiból olvassa ki, HTTPS-kérést indít, nem követi az átirányításokat, és eltárolja a válaszkódokat. A Microsoft szerint a tesztet a hosztolt ügynökbe épített diagnosztikai eszközzel kell futtatni. Ugyanez a kód egy fejlesztői munkaállomáson nem ellenőrzi a hosztolt ügynök kimenő hálózati határát.
Audit módban a tényleges hívásokat össze kell vetni a tiltandóként azonosított eseményekkel. Ehhez az ügynök futtatásának hálózati döntési nyomai vagy a projekt Application Insights-rekordjai használhatók. Egy hiányzó esemény önmagában nem bizonyítja, hogy a hívást engedélyezték.
A Microsoft hangsúlyozza, hogy a hálózati kimeneti szabályozás jelenleg nem GA, nincs hozzá előzetes verziós szolgáltatási szintű garancia, és a bemutató fejlesztési, illetve értékelési célokra készült. A dokumentáció az Audit után egy külön, azonos forrásból létrehozott Enforced szabályzat tesztelését írja le, amelyben csak a hálózati mód változik.
Microsoft Foundry: Control where your hosted agent connects with network egress in Foundry Agent Service
