Menu

cloudservices

featured_image

A Microsoft AI platform evolúciója: OpenAI és Foundry

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |

Nem rég fejeztem be egy videós képzési anyagot a Mentor Klub részére, ahol a résztvevők megismerhették az Azure-on belül elérhető OpenAI megoldásokat. Ennek részeként bemutattam az Azure OpenAI Studio felületét is, ami valójában az Azure AI Foundry egyik funkcionális eleme. Mindkettőt elég gyakran használom, különböző projektekben és különböző célokra. Hogy éppen melyik a jobb egy adott feladathoz, azt többnyire az aktuális projekt igényei döntik el.

A Microsoft azonban az elmúlt hónapokban egy olyan változtatást indított el, amely alapjaiban alakítja át azt, ahogyan eddig AI-megoldásokat építettünk Azure-ban. A Foundry platform fokozatosan átveszi az Azure OpenAI Studio szerepét, kiszélesítve annak lehetőségeit és egységesítve az AI-fejlesztés teljes ökoszisztémáját.

Mi volt az Azure OpenAI Studio szerepe

A Microsoft az Azure OpenAI Studio felületet arra hozta létre, hogy egyszerű legyen kipróbálni és tesztelni az Azure által kínált OpenAI modelleket. A felület segítségével lehetett:

  • modelleket kipróbálni egy játszótérben
  • finomhangolt modelleket kezelni
  • API-végpontokat és kulcsokat elérni
  • kötegelt feldolgozást és tárolt befejezéseket használni
  • értékeléseket futtatni
  • és még sok hasznos AI programozást segítő funkciót.

Az Azure OpenAI Studio azonban alapvetően egy modelltípusra, az Azure által értékesített OpenAI modellekre épült. Ez a projektjeim során is érezhető volt: ha más modellgyártó megoldását szerettem volna használni, akkor azt külön kellett integrálni vagy külső szolgáltatásból kellett elérni.

Ez az a pont, ahol a Foundry teljesen más szemléletet hoz.

Mit kínál a Microsoft Foundry?

A Microsoft Foundry egy egységes AI-platform, amely több modellszolgáltatót, több szolgáltatást és teljes életciklus-kezelést egy felületre hoz. A Microsoft Learn dokumentum így fogalmaz: a Foundry egy nagyvállalati szintű platform, amely ügynököket, modelleket és fejlesztői eszközöket egy helyen kezel, kiegészítve beépített felügyeleti, monitorozási és értékelési képességekkel .

A legfontosabb különbségek a következők.

Széles modellkínálat

Az Azure OpenAI-val szemben a Foundry nem korlátozódik egyetlen gyártóra. Elérhetők többek között:

  • Azure OpenAI modellek
  • DeepSeek
  • Meta
  • Mistral
  • xAI
  • Black Forest Labs
  • Stability, Cohere és más közösségi modellek

És ez még csak a jéghegy csúcsa.

Ügynökszolgáltatás és többügynökös alkalmazások (AgenticAI)

A Foundry API kifejezetten ügynökalapú fejlesztéshez készült, ahol több modell és komponens együttműködésére van szükség.

Egységes API különböző modellekhez

A Foundry egységes API-t biztosít, így a fejlesztőnek nem kell minden gyártó logikáját külön megtanulnia.

Vállalati funkciók beépítve

A Foundry felületén eleve jelen vannak:

  • nyomkövetés
  • monitorozás
  • értékelések
  • integrált RBAC és szabályzatok
  • hálózati és biztonsági beállítások

Gyakorlatilag, minden ami a nagyvállalati és biztonságos működéshez elengedhetetlen.

Projektalapú működés

A Foundry projektek olyan elkülönített munkaterületek, amelyekhez külön hozzáférés, külön adatkészletek és külön tároló tartozik. Így egy projektben lehet modelleket, ügynököket, fájlokat és indexeket is kezelni anélkül, hogy más projektekhez keverednének.

Hogyan kapcsolódik össze a két világ

A Microsoft nem megszünteti az Azure OpenAI-t, hanem lehetővé teszi, hogy az adott erőforrás Foundry-erőforrássá alakuljon. A frissítési folyamat lényege:

  • a meglévő végpontok és kulcsok megmaradnak
  • a finomhangolt modellek és állapotok megmaradnak
  • a Foundry funkciói azonnal elérhetővé válnak
  • a fejlesztő továbbra is használhatja az Azure OpenAI API-t

Mindezt lépésről lépésre írja le a frissítési útmutató.

Egy példán keresztül…

Amikor még csak Azure OpenAI-val dolgoztam, előfordult, hogy egy ügyfél Meta vagy Mistral modellt szeretett volna kipróbálni összehasonlításként. Ezt külön rendszerben kellett megoldani.
A Foundry megjelenésével ugyanabban a projektben elérhetővé vált:

  • GPT-típusú modell
  • Mistral
  • Meta
  • DeepSeek
  • és még sok más

Egy projekten belül egyszerre lehet kísérletezni, mérni és értékelni különböző modellek viselkedését.

Mit jelent ez a felhőben dolgozó szakembereknek

A Foundry nem egyszerűen egy új kezelőfelület. A gyakorlati előnyei:

  • Egységes platform, kevesebb különálló eszköz
  • Könnyebb modellválasztás és modellváltás
  • Átláthatóbb üzemeltetés, biztonság és hálózatkezelés
  • Bővíthető modellkínálat
  • Konszolidált fejlesztői élmény és API

A dokumentáció többször hangsúlyozza, hogy a Foundry nemcsak kísérletezésre, hanem üzleti szintű, gyártásra kész alkalmazásokra is alkalmas. Ez a mindennapi munkában is érezhető.

Miért előnyös ez a vállalatoknak

A vállalatok számára a Foundry több szempontból stratégiai előrelépés:

  • Egységes biztonsági és megfelelőségi keretrendszer
  • Több modellgyártó támogatása egy platformon
  • Könnyebb üzemeltetési kontroll
  • Gyorsabb AI-bevezetési ciklus
  • Rugalmasabb fejlesztési irányok

A Foundry megjelenésével a cégek már nem csak egyetlen modellre vagy ökoszisztémára építenek, hanem több szolgáltató képességét is bevonhatják anélkül, hogy töredezett lenne a rendszer.

TulajdonságAzure OpenAIFoundry
Közvetlenül az Azure által értékesített modellekCsak Azure OpenAIAzure OpenAI, Black Forest Labs, DeepSeek, Meta, xAI, Mistral, Microsoft
Partner és Közösség modellek a Marketplace-en keresztül – Stability, Cohere stb.✅
Azure OpenAI API (köteg, tárolt befejezések, finomhangolás, értékelés stb.)✅✅
Ügynökszolgáltatás✅
Azure Foundry API✅
AI-szolgáltatások (beszéd, látás, nyelv, tartalomértés)✅

Összegzés

Az Azure OpenAI Studio jó kiindulási pont volt az Azure AI-képességeinek megismerésére és modellek kipróbálására.

A Microsoft Foundry azonban túlnő ezen a szerepen:
egységes platformot biztosít a teljes AI-fejlesztési életciklushoz, több modellgyártóval és kiterjesztett vállalati funkciókkal.

A Microsoft nem leváltja az Azure OpenAI-t, hanem beépíti egy nagyobb, átfogóbb rendszerbe. Ez a lépés hosszú távon kiszámíthatóbb, hatékonyabb és sokkal rugalmasabb AI-fejlesztést tesz lehetővé.

kubernetes-api

Kubernetes API és hozzáférés – a kommunikáció idegrendszere

, , , , , , ,

| Olvasási idő: 4 perc |

Ha elég időt töltünk Kubernetes környezetben, egy ponton elkerülhetetlenül rájövünk, hogy a sok látható elem – kapszulák, szolgáltatások, vezérlők, automatizmusok – mögött van valami közös, csendben működő hatalom. Valami, ami minden változtatást, minden lekérdezést, minden döntést összeköt. Ez az API.

Egy láthatatlan infrastruktúra-háló, amely összefogja a fürt egészét, irányítja az adatáramlást, és biztosítja, hogy a rendszer minden része ugyanazt a nyelvet beszélje. Amikor ezt megértjük, nem csak használjuk a Kubernetest – elkezdjük igazán érteni.

Az API a Kubernetes motorja

A Kubernetes teljes architektúrája API-alapú. A központi komponens, a kube-apiserver, felel azért, hogy a fürtben futó összes komponens — a vezérlősík elemei és a külső kliensek — megbízhatóan kommunikáljanak egymással.
Minden, amit a kubectl paranccsal végzünk, valójában egy REST-alapú API hívás, amely HTTP metódusokat (GET, POST, DELETE stb.) használ.

Aki szeretne mélyebben belelátni a működésbe, kipróbálhatja a curl-alapú lekérdezéseket is. A megfelelő tanúsítványok birtokában például így kérhetjük le az aktuális kapszulák (Pods) listáját:

curl --cert user.pem --key user-key.pem \
 --cacert /path/to/ca.pem \
 https://k8sServer:6443/api/v1/pods

Ezek a hívások teszik lehetővé, hogy akár automatizált rendszerek, akár fejlesztői eszközök biztonságosan kapcsolódjanak a Kubernetes API-hoz.

A RESTful szemlélet ereje

A Kubernetes API RESTful, vagyis állapotmentes és erőforrás-orientált.
Minden objektum – például egy kapszula vagy egy szolgáltatás – egy konkrét API-végpont (endpoint) mögött található.
A /api/v1/pods például a kapszulákhoz tartozó végpont, ahol a GET lekérdezés listát ad, a POST pedig új kapszulát hoz létre.
Ez a megközelítés lehetővé teszi, hogy a Kubernetes könnyen integrálható legyen bármely modern fejlesztési vagy üzemeltetési eszközzel.

Jogosultságok és hozzáférés-ellenőrzés

A Kubernetes egyik legfontosabb biztonsági alapelve, hogy minden felhasználó csak azt tehessen meg, amire jogosultsága van.
Ezt az RBAC (Role-Based Access Control) rendszer szabályozza, de már a gyakorlati munkához is jól jön, ha gyorsan ellenőrizni tudjuk, mire van engedélyünk.

A kubectl auth can-i parancs pontosan erre való:

kubectl auth can-i create deployments
yes
kubectl auth can-i create deployments --as robert
no
kubectl auth can-i create deployments --as robert --namespace developer
yes

A fenti példában látható, hogy a „robert” nevű felhasználó csak a developer névtérben (namespace) hozhat létre új Deployment objektumokat.

A Kubernetes három fő API-t biztosít az engedélyek ellenőrzésére:

API típusFunkció
SelfSubjectAccessReviewEllenőrzi, hogy az aktuális felhasználó végrehajthat-e egy adott műveletet.
LocalSubjectAccessReviewUgyanez, de egy konkrét névtérre korlátozva.
SelfSubjectRulesReviewMegmutatja, milyen műveleteket hajthat végre a felhasználó egy névtérben.

Ez a felépítés biztosítja, hogy a jogosultságok átláthatóak és ellenőrizhetőek legyenek, ami különösen fontos nagyvállalati környezetben.

Optimista konkurencia – amikor több kéz nyúl ugyanahhoz az objektumhoz

A Kubernetes nem zárja le az erőforrásokat szerkesztés közben.
Ehelyett az úgynevezett optimista konkurenciakezelést (Optimistic Concurrency) használja, amely a resourceVersion értékre támaszkodik.

Amikor valaki módosít egy objektumot, a rendszer ellenőrzi, hogy a resourceVersion azóta megváltozott-e.
Ha igen, 409 CONFLICT hibát kapunk, ami jelzi, hogy az objektumot időközben más is frissítette.
Ez a módszer különösen fontos nagy fürtök esetén, ahol több automatizált folyamat és emberi adminisztrátor is dolgozik egyszerre ugyanazokon az erőforrásokon.

A resourceVersion értéket az etcd adatbázis kezeli, és egyedileg azonosítja az adott objektumot a névtér és a típus alapján.
A lekérdezések (GET, WATCH) nem változtatják ezt az értéket, csak a módosítások (UPDATE, PATCH, DELETE).

Annotációk – amikor a metaadat többet mond, mint ezer címke

A Kubernetes-ben a címkék (labels) segítségével szűrhetünk és csoportosíthatunk objektumokat.
Az annotációk (annotations) viszont nem keresésre, hanem metaadatok tárolására szolgálnak.
Ezek lehetnek időbélyegek, kapcsolódó objektumokra mutató hivatkozások, vagy akár az adott erőforrásért felelős fejlesztő e-mail-címe.

Az annotációk kulcs–érték párok formájában tárolódnak, és ember számára is olvashatóak.
Ez különösen hasznos lehet integrációs vagy üzemeltetési eszközök számára, mivel így minden releváns információ közvetlenül az objektumhoz kapcsolható.

Példa annotációk létrehozására és módosítására:

kubectl annotate pods --all description='Production Pods' -n prod
kubectl annotate --overwrite pod webpod description='Old Production Pod' -n prod
kubectl annotate -n prod pod webpod description-

Az annotációk segítségével tehát kontextust adhatunk az erőforrásainkhoz – anélkül, hogy az API működését befolyásolnánk.

Összegzés

A Kubernetes API nem csupán egy technikai interfész, hanem a platform idegrendszere.
A RESTful megközelítés, a precíz hozzáférés-kezelés, az optimista konkurencia és a rugalmas annotációk mind azt a célt szolgálják, hogy a rendszergazdák és fejlesztők hatékonyan, biztonságosan és átláthatóan kezeljék a komplex felhős környezeteket.

Aki megérti az API működését, valójában a Kubernetes egészét érti meg.
És bár a kapszulák futtatása látványosabbnak tűnhet, az igazi varázslat mégis itt, az API hívások szintjén történik.

url_featured_image

Az URL-ek működése és szerepe a modern felhővilágban

, , , , , , , , , , ,

| Olvasási idő: 4 perc |

Több tucat cikket olvashattatok tőlem a felhőszolgáltatások alapfogalmairól, és arról is, hogyan kommunikálnak egymással a különböző rendszerek. Ebben a cikkben egy olyan területet hozok közelebb, amely látszólag egyszerűnek tűnik, mégis meglepően sok félreértés forrása.

Egy saját történettel kezdem: amikor először készítettem több rétegű felhős alkalmazást, órákon át kerestem, miért nem érhető el a szolgáltatásom. A hiba mindössze annyi volt, hogy egy helytelenül megadott URL miatt teljesen más címre irányítottam a kéréseket. Ez volt az első alkalom, amikor igazán megértettem, mennyire fontos a pontos URL-használat.

A felhőben dolgozó szakemberek nap mint nap találkoznak API-végpontokkal, szolgáltatási URL-ekkel, konténerek belső hivatkozásaival és különböző load balancer címsémákkal. Ezek mind egy közös alapelvre épülnek: az URL szerkezetére. Ahhoz, hogy valaki magabiztosan mozogjon bármelyik felhős platformon, elengedhetetlen, hogy pontosan értse, mit is jelent egy URL, és hogyan működik.

Mi az az URL és miért létezik?

Az URL (Uniform Resource Locator) egy szabványos formátum, amely meghatározza, hogy az interneten vagy egy privát hálózaton belül hol található egy erőforrás, és milyen protokollon keresztül lehet elérni. A weboldalak címe, egy API végpontja, egy belső szolgáltatás címe: mind URL.

Példa:
https://api.evolvia.hu/gyakorlat/42

Ez nem egy véletlenszerű karakterhalmaz, hanem precízen meghatározott elemekből áll.

Egy URL szerkezete

Egy tipikus URL több kötelező és opcionális részből épül fel:

https://cloudmentor.hu:443/eleresi/ut/?lekerdezes=ertek#szekcio
└───┬──┘└─────┬──────┘└─┬─┘└────┬────┘└───────┬───────┘└──┬───┘
Protokoll Domain Port Útvonal Query Fragment

Az egyes részek szerepe:

Protokoll
Meghatározza, milyen szabályrendszerrel történik a kommunikáció.
Leggyakoribb: http, https

Domain vagy IP-cím
A cím, amelyhez a kérés érkezik.
Példák:
example.com
192.168.1.10
localhost – saját gépre mutat

Port
A szerveren futó adott szolgáltatás eléréséhez szükséges.
HTTP: 80
HTTPS: 443
API-k esetén gyakran egyedi, például: http://localhost:8080

Útvonal (Path)
Az erőforrás helye a szerveren belül.
Példa: /api/v1/orders

Query paraméterek
Opcionális adatok a kéréshez kapcsolódóan.
Példa: ?sort=asc&page=2

Fragment
Oldalon belüli hivatkozás, például egy szakaszra ugráshoz.

Gyakori URL-típusok és példák

1. Helyi fejlesztés: localhost
http://localhost:3000/api/test
Ez a saját gépre mutat, amit fejlesztők naponta használnak alkalmazások és API-k tesztelésére.

2. IP-cím alapú elérés
http://10.0.0.5:8080/health
Jellemző konténerek, virtuális gépek vagy belső hálózati szolgáltatások esetén.

3. Felhős API-végpontok
https://myapp.azurewebsites.net/api/login
https://abc123.execute-api.eu-west-1.amazonaws.com/prod/items
Ezek minden felhőszolgáltató esetén hasonló logikát követnek.

4. Belső szolgáltatás hivatkozása Kubernetesben
http://redis-master.default.svc.cluster.local:6379
Ez jól mutatja, hogy az URL nem csak internetes cím lehet, hanem klaszteren belüli erőforrás is.

Miért fontos ez a felhőben dolgozó szakemberek számára?

Egy felhőmérnök, DevOps vagy SRE munkája szinte minden nap érinti az URL-eket. API-k hívása, szolgáltatások összekapcsolása, webhookok beállítása, konténerek közötti kommunikáció, gateway routerek konfigurálása: mind olyan feladat, ahol egy hibás karakter is működésképtelenné tehet rendszereket.

Pontosan értve az URL szerkezetét:

  • gyorsabban lehet hibát keresni
  • megbízhatóbban lehet szolgáltatásokat összekötni
  • tisztábban értelmezhetők logok és monitoring adatok
  • könnyebbé válik a skálázható rendszertervezés

A felhőben minden kommunikáció URL-ekre épül. Aki érti az alapokat, stabil alapot kap a magasabb szintű architektúrákhoz.

Leggyakoribb hibák kezdők körében

  • Rosszul megadott protokoll: http helyett https
  • Port kihagyása olyan szolgáltatásnál, ahol nem alapértelmezett (alapértelmezett portok például: 80 – HTTP, 443 – HTTPS)
  • Query paraméterek helytelen formázása
  • Localhost és külső elérési címek összekeverése
  • Privát IP és publikus IP nem megfelelő használata

Ezek mind egyszerű hibák, mégis órákat vehetnek el a hibakeresésből.

HTTP és HTTPS közötti különbség

A webes kommunikáció két leggyakrabban használt protokollja a HTTP és a HTTPS. Bár a két rövidítés csak egyetlen betűben tér el, a mögöttük lévő technológiai különbség alapvetően meghatározza a biztonságot, a hitelesítést és az adatok védelmét. Felhőben dolgozó szakembereknek ez kiemelten fontos, hiszen az alkalmazások, API-k és háttérszolgáltatások nagy része érzékeny adatokat kezel.

HTTP – titkosítás nélküli kommunikáció

A HTTP (Hypertext Transfer Protocol) az alapvető webes protokoll, amely szabályozza, hogyan kommunikál a kliens és a szerver. A HTTP-ben az adatok titkosítatlan formában utaznak, vagyis bárki, aki valamilyen módon hozzáfér a hálózati forgalomhoz, elméletben képes lehet kiolvasni a küldött vagy fogadott tartalmakat. Ez ma már csak fejlesztési, belső hálózati vagy nagyon specifikus esetekben elfogadható.

HTTPS – titkosított és hitelesített kapcsolat

A HTTPS (HTTP Secure) ugyanezt a kommunikációs modellt használja, de kiegészül TLS-alapú titkosítással. A TLS (Transport Layer Security) gondoskodik arról, hogy a kliens és a szerver között áthaladó adatok ne legyenek olvashatók harmadik fél számára. Emellett a szerver hitelesítése is megtörténik tanúsítványok segítségével.

Ez azt jelenti, hogy:

  • a forgalom titkosított
  • a kliens meggyőződik arról, hogy valóban a megfelelő szerverhez csatlakozik
  • az adatok nem módosíthatók észrevétlenül útközben

Miért számít ez a felhőben?

A modern felhőalapú rendszerekben elképzelhetetlen HTTPS nélkül dolgozni. API-k, belső menedzsment felületek, mikroszolgáltatások közötti kommunikáció: mind olyan elemek, ahol a biztonság és az integritás prioritás.

A HTTPS használata azért kritikus:

  • védi a hitelesítési adatokat
  • megakadályozza az adatok lehallgatását
  • biztosítja, hogy a kliens valós szolgáltatással kommunikál
  • megfelel biztonsági előírásoknak és iparági szabványoknak

Gyakorlati különbségek a fejlesztő szemszögéből

  • A HTTPS URL-ek https:// előtaggal kezdődnek, a HTTP pedig http:// formát használ
  • A HTTPS alapértelmezett portja 443, míg a HTTP-é 80
  • HTTPS esetén szükség van tanúsítványra, amely lehet publikusan hitelesített vagy saját aláírású

Összefoglalás

Az URL nem pusztán egy webcím. Ez a modern internet egyik legfontosabb építőköve. A felhőben dolgozó szakemberek számára pedig különösen lényeges alapelem, hiszen minden szolgáltatás, API, konténer és infrastruktúra modul ezen keresztül kommunikál. Aki tisztában van az URL felépítésével és működésével, sokkal tudatosabban és gyorsabban fogja megérteni a felhős rendszerek belső működését.

k8s-mesos

Kubernetes és Apache Mesos – két világ, egy közös cél

, , , , , ,

| Olvasási idő: 3 perc |

Nagyon sok cikken keresztül ismerkedtünk már meg a Kubernetes alapjaival, azzal, hogyan működik a fürt (cluster) és miként kommunikálnak egymással a kapszulák (pods).

Most azonban kicsit messzebbre tekintünk, a történelem és a technológia határára, ahol megszületett a modern konténeres világ egyik előfutára – az Apache Mesos.

Képzeljünk el egy korszakot, amikor a nagyvállalatok még kísérleteztek azzal, hogyan lehetne hatékonyan kihasználni a szervererőforrásokat, hogyan lehetne a számítási kapacitást „elosztani” több gép között. Ebben a világban született a Mesos – és ebből nőtt ki később a Kubernetes.

A Mesos nem volt más, mint egy korai próbálkozás arra, hogy egységes erőforrás-kezelést biztosítson több gép, több alkalmazás és több adatközpont között. A Kubernetes később hasonló célokat tűzött ki, de egészen más filozófiával.

Mi a közös a Mesos és a Kubernetes között?

Távolról nézve, a Kubernetes nem különbözik alapjaiban más klaszterkezelő rendszerektől.
Mindkettőben megtaláljuk azokat az alapkomponenseket, amelyek nélkülözhetetlenek egy elosztott rendszerhez:

  • Központi vezérlő (control plane), amely API-n keresztül kommunikál és szabályozza a működést.
  • Ütemező (scheduler), amely meghatározza, hogy az egyes feladatok mely csomópontokon fussanak.
  • Tartós állapotkezelés (persistent state), amely megőrzi a klaszter konfigurációját és állapotát.

A különbségek azonban a részletekben rejlenek.
A Mesos az állapot tárolására Apache ZooKeeper-t használ, míg a Kubernetes ugyanezt a szerepet az etcd nevű kulcs-érték alapú adatbázissal valósítja meg. Ez az apró különbség nagy hatással van a rendszer rugalmasságára és egyszerűségére.

Mesos architektúra röviden

A Mesos a Apache Software Foundation egyik korai projektje volt, amely a nagyvállalati adatközpontok hatékony kihasználására született.
A rendszer két fő komponensre épül:

  1. Mesos Master – a központi vezérlő egység, amely felügyeli a rendelkezésre álló erőforrásokat, kiosztja azokat, és kezeli az ütemezést.
  2. Mesos Agent (korábban Slave) – a munkavégző csomópont, amely futtatja az alkalmazásokat vagy szolgáltatásokat.

A Mesos önmagában nem futtat alkalmazásokat, hanem más keretrendszereket (framework-eket) szolgál ki, mint például Marathon, Chronos vagy akár Hadoop. Ezek a keretrendszerek kommunikálnak a Mesos API-ján keresztül, és rajta keresztül ütemezik a feladatokat a klaszter gépeire.

Kubernetes: az új szemlélet

A Kubernetes ebből a modellből indult ki, de teljesen más irányba vitte tovább a koncepciót.
Míg a Mesos inkább általános erőforrás-menedzsment rendszer volt, a Kubernetes alkalmazáscentrikus megközelítést választott.
A célja az volt, hogy a fejlesztők és az üzemeltetők ne gépeket, hanem alkalmazásokat kezeljenek.

A Kubernetes minden eleme – a kapszulák (pods), szolgáltatások (services), vezérlők (controllers) – API-n keresztül vezérelhető, és ez a tiszta API-orientált szemlélet tette lehetővé az automatizálást, az önjavítást és a dinamikus skálázást.

Összegzés – két világ találkozása

Ha valaki ismeri az olyan rendszereket, mint az OpenStack vagy a CloudStack, az könnyen ráismer a közös vonásokra: mindegyik esetében van egy vezérlő komponens, vannak munkavégző egységek, és szükség van hálózatkezelésre, valamint állapotmegőrzésre.
Ami igazán megkülönbözteti a Kubernetest a Mesostól, az a hibatűrés, az önfelfedezés, és a skálázhatóság természetes támogatása.

A Mesos megmutatta, hogyan lehet egy klaszter erőforrásait megosztani. A Kubernetes pedig megmutatta, hogyan lehet ugyanezt egyszerűen, biztonságosan és automatizáltan megvalósítani.

A technológiai fejlődés történetében ritkán látunk olyan folytonosságot, mint ami a Mesos és a Kubernetes között húzódik.
Egyik a másik alapjait rakta le, és bár a Mesos ma már inkább a történelem része, hatása még mindig érezhető minden modern konténeres környezetben.


A Kubernetes nem forradalmat csinált – hanem evolúciót indított el.

aws_claude37_deprecation

Claude 3.7 Sonnet kivezetése az AWS Bedrock platformról

, , , , , , , , , ,

| Olvasási idő: 2 perc |

Aki régóta dolgozik AWS-el, mint én is, jól ismeri azokat az értesítéseket, amelyekben a szolgáltató biztonsági vagy karbantartási okokból módosításokat kér az infrastruktúrán. Október végén ismét érkezett egy ilyen e-mail, ezúttal az Amazon Bedrock felhasználóinak címezve. A levélben az Anthropic Claude 3.7 Sonnet modell kivezetéséről (deprecation) értesítik az ügyfeleket.

A Claude 3.7 Sonnet modellt az AWS Bedrockon keresztül sok fejlesztő és szervezet használta az elmúlt hónapokban különféle természetes nyelvi feldolgozási (NLP) és generatív AI feladatokra. Az Anthropic most hivatalosan megkezdte ennek a modellnek a kivezetését, amely több lépcsőben történik.

A legfontosabb dátumok

  • 2026. január 27. – a modell az úgynevezett Extended Access állapotba kerül. Ez a szakasz már nem tartalmaz új kvótanöveléseket, és a támogatás is korlátozott lesz.
  • 2026. április 28. – a modell End-of-Life (EOL) státuszba kerül, vagyis végleg elérhetetlenné válik. Ezt követően minden, a Claude 3.7 Sonnet modell ID-jére küldött kérés automatikusan hibát fog adni.

Érintett régiók

A változás az összes fő Bedrock-régiót érinti, többek között az európai adatközpontokat is (pl. eu-central-1, eu-north-1, eu-west-1, eu-west-3).

  • US-EAST-1
  • US-EAST-2
  • US-WEST-2
  • AP-NORTHEAST-1
  • AP-NORTHEAST-2
  • AP-NORTHEAST-3
  • AP-SOUTH-1
  • AP-SOUTH-2
  • AP-SOUTHEAST-1
  • AP-SOUTHEAST-2
  • EU-CENTRAL-1
  • EU-NORTH-1
  • EU-WEST-1
  • EU-WEST-3

Mit kell tenni?

Az AWS azt javasolja, hogy a felhasználók mielőbb váltsanak az Anthropic Claude Sonnet 4.5 modellre. Ez az új verzió fejlettebb teljesítményt és jobb biztonsági támogatást kínál.

Frissítés lépései az AWS Bedrock konzolon:

  1. Lépj be az Amazon Bedrock konzolra.
  2. A bal oldali menüben válaszd a Model catalog menüpontot.
  3. Keresd meg a Claude 3.7 Sonnet modellt, és jegyezd fel a modellazonosítót (Model ID).
  4. Ezután válaszd ki az új Claude 4.5 Sonnet modellt a listából (Model ID).
  5. A fejlesztői környezetedben (például Python SDK-ban vagy API hívásban) cseréld le a régi modellazonosítót az újra.

A dokumentációkban pontos példák is találhatók, hogyan frissíthető a modell az API-hívásokban vagy SDK-ban. Ezek a Bedrock Model IDs és a Bedrock API Reference oldalon érhetők el.

Összefoglalva

A Claude 3.7 Sonnet kivezetése egy tervezett, fokozatos folyamat, amely 2026 tavaszára zárul le. Akik jelenleg is használják a modellt, érdemes minél előbb átállni a Claude Sonnet 4.5 verzióra, hogy az alkalmazások működése zavartalan maradjon.

aws_ebs_strengths

AWS EBS alapok: SSD merevlemez virtuális gépekhez

, , , , , , , , ,

| Olvasási idő: 5 perc |

Amikor először léptél be a felhő világába – akár csak kísérletezőként –, elképzelted talán, hogy a virtuális gépeken minden „mindent a semmiből” kezdünk, és amikor ez a gép eltűnik, minden adat is vele. Nos, az Amazon Elastic Compute Cloud (EC2) kezdeti időszakában ez így is volt sokszor: az „instance store” típusú tárolók a virtuális gép életciklusához kötődtek.

Ma viszont, amikor már alkalmazás-monitoringról, mikroszolgáltatásokról és autoscaling-ről beszélünk, ott van az Amazon Elastic Block Store (EBS) – a felhőben tárolt merevlemez-megoldás.

Ha korábban már foglalkoztál azzal, hogy naplókat, metrikákat vagy adatokat felhőben kell megőrizni, akkor az EBS adja ehhez az alapot: megbízható, gyors és rugalmas tároló-eszköz. Most nézzük meg részletesen – kezdők számára is – mit jelent az EBS volume, mik az előnyei, mire használható és milyen korlátai vannak.

Mi az EBS Volume?

Az EBS volume egy virtuális blokkszintű tárolóegység, amelyet az Amazon EBS-en belül hozol létre, és amelyet egy EC2 példányhoz csatolhatsz, mintha egy fizikai merevlemezt adnál hozzá.
Fő jellemzői:

  • Az EBS volume az EC2 példánytól függetlenül is megőrzi az adatokat – tehát a tárolt információ nem vész el, ha a gépet leállítod vagy újraindítod.
  • Minden volume egy adott Availability Zone-hoz tartozik, és csak ott használható.
  • A felhasználó formázhatja, mountolhatja, olvashat és írhat rá, ugyanúgy, mint egy helyi meghajtóra.

Virtuális blokkszintű tárolóegység

Olyan felhőben létrehozott háttértár, amely az operációs rendszer számára úgy viselkedik, mint egy hagyományos merevlemez. Az adatokat blokkokra osztva tárolja és kezeli, így az alkalmazások közvetlenül olvashatják vagy írhatják ezeket a blokkokat.
A „virtuális” jelző azt jelenti, hogy nem egy konkrét fizikai lemezen, hanem a szolgáltató (például az AWS) elosztott tárolórendszerében található az adat — a felhasználó számára mégis egyetlen logikai meghajtónak látszik.

Hogyan működik a háttérben?

Bár az EBS-t úgy látjuk, mintha egy „saját” merevlemezünk lenne a felhőben, valójában nem egyetlen fizikai lemezről van szó. Az EBS mögött az Amazon belső, elosztott tárolórendszere dolgozik, amely több fizikai háttértáron, különböző szervereken tárolja és replikálja az adatokat.
Ez a felhasználó számára átlátszó: a blokkeszköz úgy viselkedik, mint egy hagyományos disk, de a valóságban több háttértár és redundáns adatmásolat biztosítja az állandóságot és a teljesítményt.
Ez a megoldás teszi lehetővé, hogy:

  • az adatok automatikusan védve legyenek hardverhiba esetén,
  • egyetlen lemezhiba ne okozzon adatvesztést,
  • az EBS skálázni tudja a háttérkapacitást emberi beavatkozás nélkül.

Tehát az EBS nem egy konkrét „disk”, hanem egy blokkszintű, hálózaton keresztül elérhető tárolószolgáltatás, amelyet az AWS menedzsel helyetted.

Erősségek és lehetőségek

Megbízhatóság és tartósság

Az EBS automatikusan több alrendszer között replikálja az adatokat, így egy hardverhiba sem okoz adatvesztést. Ha az EC2 példány leáll, az EBS adatai akkor is megmaradnak (amennyiben a beállítás ezt engedi).

Skálázhatóság és rugalmasság

Ennek egyik legnagyobb előnye, hogy a méretét, típusát vagy IOPS-értékét akár működés közben is módosíthatod.
Az AWS több típusú EBS volument kínál: SSD-alapú (pl. gp2, gp3, io1, io2) és HDD-alapú (pl. st1, sc1) változatokat. Az előbbiek gyors, tranzakciós feladatokra, az utóbbiak nagy adatátviteli igényű munkákra ideálisak.

Biztonság és mentés

Az EBS snapshot segítségével pillanatképet készíthetsz a volume-ról, amelyet később visszaállíthatsz, vagy akár más régióba is átmásolhatsz.
Támogatja a titkosítást is: a KMS-kulcsokkal titkosíthatók a volume-ok és snapshotok, így az adatok védettek mind tárolás, mind átvitel közben.

Típusok

Az Amazon EBS (Elastic Block Store) többféle volume típust kínál, amelyek különböző teljesítmény- és költségigényekhez igazodnak. Ezeket alapvetően két fő kategóriába soroljuk: SSD-alapú (alacsony késleltetésű, tranzakciós műveletekre) és HDD-alapú (nagy áteresztésű, szekvenciális feldolgozásra) kötetekre.

SSD-alapú volume-ok (alacsony késleltetésű, gyors műveletekhez)

Ezek ideálisak operációs rendszerekhez, adatbázisokhoz, webalkalmazásokhoz és más tranzakciós jellegű munkákhoz.

TípusJellemzőIdeális felhasználásTeljesítmény / IOPSÁrszint
gp3 (General Purpose SSD, új generáció)Alapértelmezett típus. Fix áron magasabb teljesítményt ad, mint a gp2.Általános célú alkalmazások, web- és adatbázisszerverek.Alap: 3 000 IOPS, 125 MB/s; max: 16 000 IOPS, 1 000 MB/sKöltséghatékony
gp2 (General Purpose SSD, régi generáció)Régebbi típus, teljesítmény a mérettől függ.Olyan rendszerek, ahol nem kritikus a skálázhatóság.3 IOPS / GB (max 16 000 IOPS)Közepes
io1 (Provisioned IOPS SSD)Nagy teljesítmény, garantált IOPS.Kritikus adatbázisok, pl. Oracle, SAP HANA.100 – 64 000 IOPSMagas
io2 (Provisioned IOPS SSD, új generáció)Jobb tartósság (99,999%) és magasabb IOPS-arány.Nagyvállalati adatbázisok, alacsony késleltetést igénylő alkalmazások.100 – 256 000 IOPSMagas

HDD-alapú volume-ok (nagy adatátvitel, olcsóbb)

Ezeket főként nagy mennyiségű, szekvenciális adat feldolgozására használják, például logok, biztonsági mentések, adatarchívumok esetén.

TípusJellemzőIdeális felhasználásÁtviteli sebességÁrszint
st1 (Throughput Optimized HDD)Nagy áteresztés, költséghatékony tárolás.Nagy adatfolyamot kezelő rendszerek (pl. log-elemzés, Big Data).Max 500 MB/sAlacsony
sc1 (Cold HDD)Archív, ritkán elérhető adatokhoz.Biztonsági mentések, ritka hozzáférésű adatok.Max 250 MB/sLegolcsóbb

Összehasonlítás röviden

KategóriaTípusokTeljesítményKöltségTartósságFő cél
SSDgp3, gp2, io1, io2Nagyon gyorsKözepes–magas99,8–99,999%Adatbázis, OS, tranzakciók
HDDst1, sc1MérsékeltAlacsony99,8%Archívum, log, backup

Egyszerű példák

  • Webalkalmazás: van egy EC2-n futó weboldalad, amely adatbázist használ. Külön EBS volument csatolsz az adatbázishoz, így az adatok nem vesznek el akkor sem, ha a példányt újratelepíted.
  • Adatfeldolgozás: egy log-gyűjtő rendszer nagy mennyiségű adatot olvas és ír. Ilyenkor érdemes nagy áteresztésű, HDD-alapú (pl. st1) EBS-t választani.

Szolgáltatási szint (SLA)

Az AWS az EBS-re 99,999%-os tartóssági és 99,99%-os rendelkezésre állási szintet vállal.
Ez a gyakorlatban azt jelenti, hogy évente mindössze néhány percnyi szolgáltatáskiesés valószínű.
A tartóssági garancia kifejezetten magas: az AWS belső infrastruktúrája több adatmásolatot tart, így az adatok elvesztésének esélye rendkívül alacsony.

Ugyanakkor ez nem jelenti azt, hogy nincs szükség mentésre – az AWS maga is javasolja a rendszeres snapshot-készítést, hiszen az SLA csak a szolgáltatás elérhetőségére és megbízhatóságára, nem pedig az emberi hibákból eredő adatvesztésre vonatkozik.

Hogyan segíti a cégeket és felhasználókat

  • Gyorsan növekvő szoftvercég az EBS-t használhatja skálázható háttértárként: ha nő az ügyfélbázis, a volume-ot egyszerűen bővíthetik vagy nagyobb teljesítményűre cserélhetik, leállás nélkül.
  • Egy startup az alacsonyabb árú, gp3 típusú volume-val indíthatja el alkalmazását, így kezdetben nem kell túlfizetnie a tárolásért.
  • Kisvállalkozás, amely webáruházat működtet az AWS-en, EBS-t használhat a vásárlói adatok és képek biztonságos, tartós tárolására.

Korlátok és megfontolások

  • Egy EBS volume csak abban az Availability Zone-ban használható, ahol létrejött.
  • A díjazás méret- és típusfüggő, és a lefoglalt kapacitás után fizetsz, nem a tényleges használat után.
  • A teljesítményt a választott volume-típus és az EC2 példány típusa együtt határozza meg.
  • Az EBS általában csak egy példányhoz csatolható; több géphez csak speciális beállításokkal.
  • Az adott régió kiesése esetén a volume is elérhetetlenné válhat, ezért érdemes snapshotokkal biztonsági mentést készíteni.

Összegzés

Az AWS EBS volume egy megbízható, tartós és skálázható blokktárolási megoldás, amely ideális választás virtuális gépekhez. Segítségével az adatok függetlenek maradnak az EC2 példány életciklusától, könnyen bővíthetők, és egyszerűen menthetők snapshotokkal.

Erősségei közé tartozik a stabilitás, a gyors adatkezelés, a rugalmas méretezhetőség és a titkosítási lehetőség. Ugyanakkor érdemes figyelni az elérhetőségi zónák korlátaira és a költségek optimalizálására.
Ha a felhőben adatbázist, webalkalmazást vagy akár nagy adatfeldolgozó rendszert építesz, az EBS az egyik legfontosabb építőkockád lesz – megbízható, mint egy jó merevlemez, csak épp a felhőben.

azure-tarfiok-tls

Frissítés szükséges: csak TLS 1.2 az Azure Tárfióknál

, , , , , ,

| Olvasási idő: 2 perc |

Aki régen dolgozik Azure-ban, mint én is, rendszeresen kap értesítő e-maileket, amelyekben biztonsági okokból kérik a felhasználót az infrastruktúra módosítására. Most is jött egy ilyen, október elején: a Microsoft arra figyelmeztet, hogy az Azure Tárfiókoknál 2026. február 3. után már csak a TLS 1.2 vagy újabb verzió lesz támogatott.

Ez az értesítés elsősorban azokat érinti, akiknek a Tárfiókjai még TLS 1.0 vagy 1.1 protokollt is elfogadnak. Ezek a régebbi titkosítási eljárások ma már elavultnak számítanak, és nem támogatják a modern kriptográfiai algoritmusokat, ezért a Microsoft fokozatosan megszünteti a használatukat.

Mi az a TLS és miért fontos?

A TLS (Transport Layer Security) egy biztonsági protokoll, amely az internetes adatátvitel védelmét szolgálja. A korábbi verziók (1.0 és 1.1) több mint 20 évesek, és ma már nem felelnek meg a biztonsági követelményeknek. A TLS 1.2 gyorsabb és biztonságosabb kommunikációt biztosít, amely jobban védi az adatokat a lehallgatás és a manipuláció ellen.

Mi a teendő?

Ha az Azure Tárfiókod TLS 1.0 vagy 1.1 protokollt is enged, akkor 2026. február 3-ig frissítened kell a beállításokat, különben az alkalmazásaid nem fognak tudni biztonságosan csatlakozni a szolgáltatáshoz.

A Microsoft ajánlása egyértelmű:

  • Állítsd be a Minimális TLS-verziót 1.2-re (vagy újabbra).
  • Ellenőrizd, hogy az alkalmazásaid és SDK-jaid is támogatják a TLS 1.2-t.

Hogyan lehet beállítani a TLS 1.2-t az Azure portálon?

A beállítás módosítása néhány kattintás az Azure portálon:

  1. Lépj be az Azure Portalba.
  2. Keresd meg a módosítani kívánt Tárfiókot.
  3. A bal oldali menüben válaszd a Beállítások > Konfiguráció (Settings > Configuration) menüpontot.
  4. A Minimális TLS-verzió (Minimum TLS version) beállításnál válaszd ki a TLS 1.2 opciót.
  5. Mentsd el a módosítást (Mentés / Save).

Ha több Tárfiókod van, érdemes Azure Policy-t is használni, hogy központilag kikényszerítsd a TLS 1.2 beállítást minden fiókra.

Meddig van időm ezt elvégezni?

A határidő 2026. február 3., eddig kell minden Tárfiókon elvégezni a frissítést. Ezt követően a TLS 1.0 és 1.1 kapcsolatokat az Azure Tárfiók már nem fogadja el.

Aki addig nem módosítja a beállításokat, annak az alkalmazásai hibát fognak adni, amikor megpróbálnak kapcsolódni a Tárfiókhoz.

Összefoglalás

A változás célja, hogy az Azure-felhasználók biztonságosabb és korszerűbb titkosítási eljárásokat használjanak. A frissítés mindössze néhány percet vesz igénybe, de elengedhetetlen a jövőbeni hibamentes működéshez.

aws-outage

AWS szolgáltatáskiesés és tanulságok a megbízhatóságról

, , , , ,

| Olvasási idő: 3 perc |

A felhőben a rendelkezésre állás és a hibatűrés kulcsfontosságú, hiszen a legtöbb vállalat napi működése az ilyen szolgáltatásokra épül.
Az Amazon Web Services (AWS) például 99,99%-os SLA-t (Service Level Agreement) vállal a legtöbb szolgáltatására, ami éves szinten mindössze egy órányi megengedett leállást jelent.
Ennek ellenére időnként előfordulhatnak átmeneti fennakadások – ilyen volt a 2025. október 20-i esemény is, amely jól demonstrálta, mennyire gyorsan képes reagálni az AWS egy globális szintű problémára.

A hiba gyökere az US-East-1 (Észak-Virginia) régióban jelentkezett, és több mint 140 AWS-szolgáltatás működésére is kihatott – különösen azokra, amelyek DNS-feloldásra vagy központi vezérlősíkra (control plane) támaszkodnak.

Bár az európai (Frankfurt, EU-Central-1) régió nem volt közvetlenül az esemény központja, számos szolgáltatás itt is tapasztalt átmeneti hibákat. Ennek oka, hogy több globális AWS-komponens – például az IAM/SAML bejelentkezés, az ECR image-tárolás vagy a globális API-végpontok – részben az US-East-1-hez kapcsolódik.

Hivatalos idővonal (CEST)

  • 09:11 – AWS vizsgálja a megnövekedett hibaarányokat és késéseket több szolgáltatásban (US-EAST-1).
  • 09:51 – A hibák megerősítést nyernek, az AWS Support API és konzol is érintett.
  • 10:26 – A DynamoDB végpontoknál jelentős hibák lépnek fel, további szolgáltatások is érintettek.
  • 11:01 – Az AWS azonosítja a probléma lehetséges okát: DNS-feloldási hiba a DynamoDB végpontnál.
  • 11:22 – Kezdeti helyreállítási jelek tapasztalhatók néhány szolgáltatásnál.
  • 11:27 – Jelentős javulás, a legtöbb kérés már sikeresen teljesül.
  • 12:03 – A globális szolgáltatások (IAM, DynamoDB Global Tables) is helyreállnak.
  • 12:35 – A DNS-hiba teljesen elhárítva, a legtöbb művelet ismét normálisan működik.
  • 13:08 – 14:10 – Az EC2 indítási hibák és a Lambda polling-késések fokozatosan javulnak.
  • 14:48 – 15:48 – Az EC2 indítási korlátozások enyhülnek, a legtöbb Availability Zone újra működik.
  • 16:42 – 18:43 – A hálózati terheléselosztó (Network Load Balancer) egészség-ellenőrző alrendszer hibát okoz több szolgáltatásban (Lambda, CloudWatch, DynamoDB).
  • 18:43 – 20:13 – További mitigációk, a hálózati problémák fokozatosan megszűnnek.
  • 20:22 – 21:15 – Szinte minden AWS szolgáltatás helyreállt, csak néhány EC2-indítás és Lambda maradt részben érintett.
  • 22:03 – 23:52 – Teljes szolgáltatás-visszaállás az US-EAST-1 régióban.
  • 00:01 (október 21.) – Az AWS hivatalosan is normál működést jelent.

Hatások és tapasztalatok

A kiesés során világszerte számos ismert platform – többek között a Snapchat, a Fortnite, a Reddit és a Venmo – részleges vagy teljes leállást tapasztalt.
A felhőszolgáltatások közötti erős függőségek miatt a hiba nem csupán az AWS-t érintette, hanem több külső rendszer és alkalmazás működésében is zavart okozott.

A vizsgálat szerint a probléma nem biztonsági incidens vagy kibertámadás következménye volt, hanem egy belső DNS-feloldási hiba, amely a DynamoDB szolgáltatás elérhetetlenségéhez vezetett, majd tovagyűrűzött az azt használó szolgáltatásokon keresztül.

Tanulságok

Az AWS kiesése emlékeztetett arra, hogy még a legnagyobb globális felhőszolgáltatók esetében is előfordulhatnak ritka, rövid ideig tartó fennakadások.
Fontos azonban kiemelni, hogy az ilyen események rendkívül ritkák, és az AWS gyors helyreállítási folyamatai miatt a szolgáltatások általában néhány órán belül normalizálódnak.

Ez az eset is jól mutatta az AWS infrastruktúra érettségét és reakcióképességét – a hibát hamar azonosították, a helyreállítás fokozatosan zajlott, és az ügyfelek többsége számára a szolgáltatások néhány órán belül elérhetővé vált.
Az esemény így inkább megerősítette, mintsem gyengítette a felhőszolgáltatásokba vetett bizalmat: az AWS ökoszisztéma bizonyította, hogy képes gyorsan és hatékonyan kezelni váratlan globális problémákat.

Te mit gondolsz erről?

github_token_pat_security

GitHub token kezelés és változások: Personal Access Token

, , , , , , ,

| Olvasási idő: 4 perc |

Amikor fejlesztőként program csomagokat publikálunk vagy automatizálunk, a biztonság mindig kulcskérdés. A szoftverellátási lánc támadásai egyre gyakoribbak, ezért a GitHub most javította a hitelesítést és a token-kezelést.
Az egész folyamat középpontjában a Personal Access Token (PAT) áll — ez az a digitális kulcs, ami a fejlesztők mindennapjait biztonságosabbá és szabályozottabbá teszi.

Mi az a PAT, és miért fontos?

A Personal Access Token (PAT) egy digitális azonosító, amellyel hitelesítem magam a GitHub-on vagy az npm-en anélkül, hogy jelszót kellene megadnom.
Olyan, mint egy személyre szabott kulcs, amivel belépek egy zárt rendszerbe – de csak azokhoz az ajtókhoz, amelyekhez ténylegesen van jogosultságom.

A PAT azért fontos, mert:

  • Biztonságosabb, mint a jelszó, nem kerül közvetlenül a kódba vagy pipeline-ba.
  • Automatizált folyamatokhoz (CI/CD, build, deploy) elengedhetetlen, mivel emberi beavatkozás nélkül hitelesít.
  • Korlátozható és forgatható, így ha kiszivárog, a kár minimalizálható.

Más szóval: minden, amit a fejlesztői rendszerekben „tokenk-ént” használunk — legyen az npm, GitHub vagy API — valójában egy Personal Access Token, csak más néven vagy kontextusban jelenik meg.

A token típusok közötti különbségek

A GitHub háromféle token-mechanizmust használ — ezek közül az első volt a klasszikus PAT, a második a továbbfejlesztett granularis verzió, a harmadik pedig már a PAT nélküli jövő.

1. Klasszikus PAT (Classic Token) – a régi hozzáférés

A klasszikus PAT hatókörös, tehát megadható, milyen tág jogosultságokkal rendelkezik (pl. repo). Ugyanakkor a hatóköre nem elég finom (jellemzően minden repo, amihez a felhasználónak hozzáférése van), és a lejárat nem volt kötelező – emiatt nagyobb a kockázat, ha kiszivárog.

2. Granularis PAT (Fine-grained Access Token) – a finomítás

A granularis PAT bevezetésével a GitHub sokkal precízebb jogosultságkezelést adott a kezünkbe.
Beállíthatom, hogy:

  • pontosan mely repository-hoz fér hozzá,
  • milyen műveletekre jogosít (pl. olvasás, írás, admin),
  • és meddig érvényes legyen (alapértelmezés szerint 7 nap, maximum 90).

Ez csökkenti a támadási felületet, és jobban illeszkedik a vállalati biztonsági irányelvekhez is.

3. OIDC / Trusted Publishing – alternatíva pipeline-hoz

A Trusted Publishing nem azt jelenti, hogy megszűnnek a Personal Access Token-ek (PAT) – sok esetben továbbra is szükség van rájuk – hanem azt, hogy egy biztonságosabb alternatívát kínál az automatizált csomag-kezeléshez. Ebben a megközelítésben a CI/CD rendszer (például GitHub Actions vagy GitLab CI/CD) az OpenID Connect (OIDC) protokollt használja, és rövid életű hitelesítést kap az adott csomag-registry (pl. npm) felé. Így a folyamat során nem kell előre létrehozott vagy tárolt PAT-et használnom, mert a futás idejére automatikusan generálódik a jogosultság.

Ez a megközelítés jelentősen csökkenti a token-kezelés kockázatát – nincs olyan hosszú életű kulcs, amit elfelejtek forgatni vagy ami kiszivároghat –, de nem helyettesíti a PAT-eket más típusú műveletekhez vagy API-hívásokhoz.
A Trusted Publishing jelenleg támogatott a GitHub Actions és GitLab CI/CD környezetben, és egyre több CI-platform fogja követni ezt az irányt.

Mi változik most konkrétan?

A GitHub az npm ökoszisztémán keresztül vezeti be a PAT-kezelés első nagy változását.
A mostani frissítés három fő területet érint, és minden esetben jól látszik, hogyan változik a korábbi működés.

TerületKorábbi állapotÚj szabály
PAT élettartamA tokenek alapértelmezett lejárata 30 nap volt, a klasszikus PAT akár korlátlanul is élt.Az új granularis PAT alapértelmezett lejárata 7 nap, maximum 90 nap.
Klasszikus PAT-ekTovábbra is használhatók voltak, teljes hozzáféréssel.Teljes kivezetés: 2025 november közepétől minden klasszikus PAT érvénytelen lesz.
2FA hitelesítésTOTP-alapú (időzített kódos) kétlépcsős azonosítás.WebAuthn/passkey alapú 2FA váltja, ami ellenáll a phishing-támadásoknak.

Ezek a változások október közepétől indulnak, és november közepéig minden klasszikus token megszűnik.

Példák, ahol PAT-et használunk

  1. CI/CD pipeline-ban: amikor a GitHub Actions új verziót publikál npm-re, PAT segítségével hitelesít.
  2. Helyi fejlesztéskor: a git push vagy npm publish művelet PAT alapján engedélyezett.
  3. Integrációs eszközöknél: például a Dependabot vagy a Renovate PAT-tel fér hozzá a repo-hoz, hogy automatikus frissítéseket küldjön.

Hogyan készülj fel?

  1. Új granularis PAT-eket hozol létre, és minden pipeline-ban lecseréled a régieket.
  2. Áttérsz az OIDC-alapú Trusted Publishing használatára, ahol lehetséges.
  3. Rendszeresen rotálod a még meglévő PAT-eket.
  4. Bevezeted a WebAuthn alapú 2FA-t, hogy megerősítsed a fiókom védelmét.

Összegzés

A Personal Access Token-ek (PAT) a modern fejlesztői hitelesítés alapját jelentik.

Különösen fontos felhő megoldásokkal való integrálásnál (pl. Azure DevOps Pipelines vagy AWS CodePipeline), mert így biztosíthatjuk, hogy csak a szükséges műveletekhez kapunk hozzáférést, és a felhőerőforrásokat is biztonságosan kezelhetjük.

A GitHub most azért változtat, hogy ezek a tokenek rövidebb életűek, korlátozottabb hatókörűek és biztonságosabbak legyenek.
Ez az átmenet az automatizált, tokenmentes jövő felé vezet — ahol az azonosítás már teljesen automatizált és emberi beavatkozás nélküli.

Én személy szerint támogatom ezt az irányt. Ez a változás nemcsak engem véd, hanem mindenkit, aki a GitHub-ra és az npm-re épít.

rbac-azure-illustration

RBAC az Azure-ban: biztonság, jogosultság és hatékonyság

, , , , , , ,

| Olvasási idő: 4 perc |

A felhőalapú technológiák rohamos terjedésével egyre nagyobb hangsúlyt kap az erőforrásokhoz való hozzáférés kezelése. Az elmúlt hónapokban már több cikkben is körbejártuk, hogyan épülnek fel a modern felhőarchitektúrák, és milyen eszközökkel tarthatók átláthatóan karban. Most azonban elérkeztünk egy olyan témához, ami nélkül minden korábbi tudás bizonytalan lábakon állna: a hozzáférés-kezeléshez. Ennek egyik legfontosabb pillére az RBAC, vagyis a Role-Based Access Control – magyarul szerepkör-alapú hozzáférés-vezérlés.

Képzeljünk el egy nagyvállalatot, ahol több száz vagy több ezer ember dolgozik különböző projekteken. Nem mindenki férhet hozzá mindenhez – a fejlesztők nem módosíthatják a pénzügyi adatokat, az adminisztrátor viszont nem feltétlenül lát bele az alkalmazás kódjába. Az RBAC éppen ezt a problémát oldja meg: egyértelműen meghatározza, ki mit tehet és mit nem.

Mi az RBAC lényege?

Az RBAC alapelve, hogy a hozzáférési jogokat nem közvetlenül a felhasználókhoz, hanem szerepkörökhöz rendeljük. Ezek a szerepkörök előre definiált engedélyeket tartalmaznak, amelyek meghatározzák, milyen műveletek hajthatók végre adott erőforrásokon.
A felhasználók ezután egy vagy több szerepkört kaphatnak – így az engedélyezés egyszerre lesz átlátható, rugalmas és könnyen kezelhető.

A koncepció három alapeleme:

  1. Felhasználók (Users) – azok a személyek vagy szolgáltatások, akik hozzáférnek az erőforrásokhoz.
  2. Szerepkörök (Roles) – engedélyek gyűjteménye, például „Reader”, „Contributor” vagy „Owner”.
  3. Hozzárendelések (Role Assignments) – ezek kapcsolják össze a felhasználót, a szerepkört és az adott erőforrást.

Hogyan működik az RBAC az Azure-ban?

Az Azure RBAC az Azure Resource Manager (ARM) modellre épül, és segítségével szabályozható, hogy ki milyen műveleteket végezhet el Azure-erőforrásokon – például virtuális gépeken, tárfiókokon, adatbázisokon vagy hálózati elemekben.

Az Azure-ban minden erőforrás hierarchikus struktúrában helyezkedik el:

  • Management Group (Felügyeleti csoport) – a legfelső szint, amely több előfizetést is összefoghat.
  • Subscription (Előfizetés) – az erőforrások logikai egysége, ahol a számlázás és az erőforrás-kvóták kezelése történik.
  • Resource Group (Erőforráscsoport) – az erőforrások rendezésére szolgáló konténer, például egy adott projekt vagy alkalmazás elemei számára.
  • Resource (Erőforrás) – az egyes Azure-szolgáltatások, például virtuális gépek, tárfiókok, adatbázisok vagy hálózati elemek.

Egy szerepkör-hozzárendelés bármelyik szinten megadható, és öröklődik a hierarchia alatti szintekre.
Ha például valaki Reader jogot kap egy teljes előfizetés szinten, akkor automatikusan olvashatja az összes erőforráscsoport és erőforrás tartalmát abban az előfizetésben.

RBAC a gyakorlatban (példa)

Képzeljük el, hogy egy fejlesztőcsapat három szereplőből áll:

  • Attila, a vezető fejlesztő
  • Péter, az infrastruktúra adminisztrátor
  • Zoli, a tesztelő

Az IT biztonsági elv szerint mindenkinek csak a munkájához szükséges jogokat adjuk meg.

  1. Attila (Contributor) – létrehozhat, módosíthat és törölhet erőforrásokat a fejlesztői Resource Group-ban, de nem kezelheti a hozzáféréseket.
  2. Péter (Owner) – teljes körű hozzáféréssel rendelkezik, így módosíthatja a szerepköröket és erőforrásokat is.
  3. Zoli (Reader) – csak megtekintheti a fejlesztési környezetben található erőforrásokat, de nem módosíthat semmit.

Ez a megközelítés egyszerre biztonságos és hatékony, hiszen mindenki csak azt látja és azt kezeli, ami a feladata ellátásához szükséges.

RBAC szerepkörök az Azure-ban

Az Azure több mint 120 beépített szerepkört kínál, de a leggyakoribbak közé tartozik:

  • Owner – teljes hozzáférés mindenhez, beleértve a hozzáférés-kezelést is.
  • Contributor – minden erőforrást módosíthat, de nem kezelheti a jogosultságokat.
  • Reader – csak olvasási hozzáféréssel rendelkezik.
  • User Access Administrator – mások jogosultságait kezelheti, de magukat az erőforrásokat nem módosíthatja.

Ezen felül lehetőség van egyedi szerepkörök létrehozására is, ha a beépített szerepkörök nem fedik le pontosan a szervezet igényeit.
Egyedi szerepkörök JSON formátumban definiálhatók, és pontosan meghatározható bennük, milyen műveletek engedélyezettek vagy tiltottak.

Az RBAC előnyei

  1. Biztonság – Csökkenti a túlzott jogosultságok kockázatát, így kevesebb az emberi hiba vagy jogosulatlan hozzáférés.
  2. Átláthatóság – Könnyen ellenőrizhető, ki milyen jogokkal rendelkezik.
  3. Skálázhatóság – Nagyvállalati környezetben is egyszerűen kezelhető a jogosultságok bővülése.
  4. Automatizálhatóság – A szerepkörök hozzárendelhetők automatizált szkriptekkel vagy Terraform kódokkal is.

Az RBAC korlátai

Bár az RBAC rendkívül hasznos, nem minden esetben elégséges.

  • Nem tudja kezelni az adatszintű hozzáféréseket (például egy SQL tábla soraira vonatkozó jogosultságokat).
  • A komplex szervezeti hierarchiákban a szerepkörök öröklődése nehezen átláthatóvá válhat.
  • Túl sok egyedi szerepkör esetén nő az adminisztrációs teher és a hibalehetőség.

Ezek miatt sok vállalat az RBAC-et kombinálja más megoldásokkal, például Azure AD (EntraID) Conditional Access vagy Privileged Identity Management (PIM) funkciókkal, amelyek ideiglenes vagy feltételes jogosultságkezelést biztosítanak.

Miért hasznos a cégek és felhasználók számára?

A cégek számára az RBAC legnagyobb előnye a kontroll és a biztonság egyensúlya.
Ahelyett, hogy mindenki korlátlanul hozzáférne mindenhez, az RBAC lehetővé teszi, hogy a hozzáférés csak a szükséges mértékben legyen biztosítva.

A felhasználók számára ez azt jelenti, hogy egyértelműen látják, mire jogosultak, és nem kell aggódniuk a véletlen hibák miatt.
Egy fejlesztő például nyugodtan dolgozhat a saját projektjén anélkül, hogy kockáztatná más rendszerek működését.
A rendszergazdák pedig gyorsabban és pontosabban tudják kiosztani az engedélyeket, akár automatizált folyamatokon keresztül is.

Összegzés

A Role-Based Access Control az egyik legfontosabb biztonsági és hatékonysági alapelv a felhőben. Az Azure RBAC egy kifinomult, de logikusan felépített rendszer, amely segít abban, hogy a szervezetek biztonságosan, mégis rugalmasan kezeljék a hozzáféréseket.

Az alapelve egyszerű: mindenkinek csak annyi jogot adjunk, amennyire valóban szüksége van.


Ez a szemlélet nemcsak az Azure-ban, hanem bármely modern informatikai környezetben elengedhetetlen, ahol a bizalom és az ellenőrzés kéz a kézben jár.

Load More