Cloud Mentor - A gyakorlati felhőtudás forrása

2025.04.17.

Helyi AI modell futtatása Dockerrel

A Docker legújabb újítása, a Docker Model Runner, egy izgalmasnak tűnő fejlesztés a generatív mesterséges intelligenciával foglalkozó szakemberek számára. A…

2025.04.14.

RAG és CAG: a pontosság vagy a sebesség az AI jövője?

A generatív mesterséges intelligencia világában már nem csak az számít, milyen nagy egy modell vagy hány milliárd paramétere van. Az […]

2025.04.11.

Fontos alapfogalmak a Kubernetes világában

Miután megismertük a Kubernetes alapvető architektúráját, érdemes néhány kulcsfontosságú fogalommal is megismerkedni. Ezekkel az objektumokkal később is dolgozunk majd, de […]

2025.04.07.

GitHub CoPilot Agent: újabb szint az asszisztált kódolásban

Habár csak néhány napja jelentették be, nekem már volt alkalmam kipróbálni a GitHub CoPilot új Agent funkcióját a Visual Studio […]

2025.04.03.

Kubernetes architektúrája – az alapok megértése

Legutóbb a mikroszolgáltatások kihívásait tárgyaltuk. Az alábbiakat kell megvalósítanunk: Erre ad nekünk választ a Kubernetes. Ahhoz, hogy valóban megértsük, hogyan […]

2025.03.31.

CloudFormation: Infrastruktúra kódként az AWS-ben

Korábban írtam már az infrastruktúra automatizálásáról és a DevOps megközelítés fontosságáról az informatikai projektekben. Ezen megközelítés neve Infrastructure as Code (IaC). A […]

2025.03.26.

IAM szerepkörök és jogosultságok az AWS-ben

Minden informatikai rendszerben kiemelkedő szerepet tölt be a jogosultságkezelés, hiszen ez határozza meg, hogy a rendszer mely részéhez ki és […]

2025.03.21.

Tanúsítvány vagy tapasztalat? A felhő karrier dilemmája

Az IT világában egyre többen fordulnak a felhőtechnológiák felé, és sokan azzal a meggyőződéssel kezdenek neki a tanulásnak, hogy egy […]

«‹ 13 14 15 16 ›»

Kategóriák

Felhő / Cloud

Felhő ABC

Mesterséges Intelligencia / AI

Videók

Határidők / Események

2026.08.31.

GCP Kivezetés

Google Cloud KMS kvótarendszer migrációja II.

🗓️ Fontos dátumok

2026. február 16. – február 27.: A migrációs folyamat aktív szakasza.
2026. augusztus 31.: A régi metrikák végleges kivezetése. Eddig az időpontig kell frissíteni minden egyedi monitorozást!

🛠️ Mi változik?

Regionális kvótaérvényesítés: A forgalom mostantól ott számít bele a kvótába, ahol a feladat fut (még multi-region forgalom esetén is).
Új metrika elnevezések: Pontosabb kategóriák érkeznek a védelem típusa szerint (software_usage, hsm_usage, etc.) és műveleti típusok alapján (read_usage, write_usage).
"Soft Enforcement": Az új metrikák többségénél a kvóta túllépése esetén is kiszolgálja a rendszer a kéréseket, amennyiben van szabad kapacitás.

✅ Teendők

Monitorozás: Ha saját dashboardokat vagy riasztásokat használtok, augusztus 31-ig írjátok át őket az új metrikákra az adatok folytonossága érdekében.
Kvóta túllépések (Overrides): A meglévő override-okat a Google automatikusan migrálja, ezzel nincs teendőtök.
Számlázás: A változás nem érinti a költségeket, a KMS számlázása továbbra is használat alapú marad.

Hasznos link

Kritikus: Ez egy fontos változás, a szolgáltatás/funkció ezen a napon megszűnik vagy megváltozik. A zavartalan működéshez beavatkozás szükséges.

2026.09.30.

GCP Biztonság Új

IAM szerepkör-változások a Google Cloudban

A Google Cloud több szolgáltatás esetén módosítja az előredefiniált IAM szerepkörök jogosultságait.
A cél az egységesebb role-definíció és az új, valamint meglévő funkciók lefedése.

➡️ Role-definíciók egységesítése:
• {Service} Admin – teljes hozzáférés az adott szolgáltatás minden műveletéhez
• {Service} Editor – erőforrások létrehozása, módosítása, törlése és használata (security policy-k nélkül)
• {Service} Viewer – read-only hozzáférés az erőforrásokhoz és konfigurációjukhoz.

⚠️ Hatás a meglévő projektekre
• A változás nem érinti a jelenlegi működést
• Az érintett felhasználók és service account-ok 2026. szeptember 30-tól automatikusan megkapják az új jogosultságokat.

⚠️ Ajánlott ellenőrzési pont
• Érdemes átnézni, hogy az új permission-ök illeszkednek-e a jelenlegi IAM és security modellhez
• Ha szükséges, a hozzáférés finomítható custom IAM role-lal vagy IAM Deny policy-vel

Ez egy role-definíciókat érintő változás, amelyet mindenkinek érdemes tudnia.

Hasznos link

Opcionális: Ez egy opcionális változás vagy kényelmi funkció, nem kötelező alkalmazni.

2027.02.27.

Azure Biztonság Migráció

Azure Key Vault: RBAC lesz az alapértelmezett

A Microsoft bejelentette az Azure Key Vault API-k eddigi egyik legjelentősebb változását. Ha az infrastruktúrádat kódból építed (IaC), erre nagyon oda kell figyelned!

🗓️ Kulcsfontosságú dátumok

2026. február: Megjelenik a 2026-02-01 API verzió, ahol már az Azure RBAC lesz az alapértelmezett modell az új vault-oknál.
2027. február 27.: Minden korábbi API verzió kivezetésre kerül (Retirement).

🛠️ Mi változik?

Eddig az új Key Vault-ok alapértelmezés szerint "Access Policy" (örökölt hozzáférési szabályok) módban jöttek létre. Az új API verzióval ez megfordul:

RBAC az új alapértelmezett: Minden újonnan létrehozott vault Azure RBAC-re lesz állítva, hacsak nem jelzed explicit módon az ellenkezőjét.
IaC hibaforrás: Ha a Terraform vagy Bicep scriptjeid nem tartalmazzák az explicit konfigurációt, az új vault-ok RBAC módban jönnek létre, a korábbi Access Policy-k pedig nem fognak működni.

✅ Mit kell tenned?

Megerősítem a Microsoft javaslatát: Migrálj Azure RBAC-re! Ez sokkal granuláltabb, biztonságosabb és a modern Azure standard-oknak megfelelő megoldás.

Teendők:

Ellenőrizd a meglévő Key Vault-jaidat, és készíts tervet az RBAC-re való áttérésre.
Frissítsd a CLI, PowerShell, ARM, Bicep és Terraform sablonjaidat.
Ha ragaszkodsz a régi Access Policy modellhez, az új API verzióra való váltáskor explicit módon be kell állítanodezt a sablonjaidban, különben az automatizációid elhasalnak.

Ha nem módosítod az automatizációs scriptjeidet, az új vault-ok 403-as hibával elutasíthatják a kéréseket.

Ne várd meg 2027-et, az új API-val járó változások már jövő februártól élesednek az új erőforrásoknál!

Hasznos link

Ajánlott: Ez egy javasolt módosítás, vagy egy új funkció. A szolgáltatás működését közvetlenül nem befolyásolja.

2027.09.30.

Azure Kivezetés Migráció

Azure LB: Kivezetik a bejövő NAT-szabályok v1-et

Az Azure nyugdíjazza a Standard Load Balancer bejövő NAT-szabályainak (Inbound NAT Rules) első verzióját. Ha jelenleg NAT-poolokat vagy v1-es szabályokat használsz, időben tervezned kell a migrációt.

🗓️ Határidő

2027. szeptember 30. (Ezt követően a v1-es szabályok nem lesznek támogatottak.)

🛠️ Mi változik?

A v2-es szabályok váltják fel a régieket, amelyek rugalmasabb konfigurációt és jobb skálázhatóságot biztosítanak. A legfontosabb különbség, hogy a v2 már nem igényel NAT-poolokat a virtuális gépcsoportokhoz (VMSS), hanem közvetlen szabálytársítást tesz lehetővé.

✅ Tennivalók

Feltérképezés: Ellenőrizd a meglévő Load Balancereidet, hogy használnak-e örökölt (v1) NAT-szabályokat vagy NAT-poolokat.
Migráció: Frissíts a v2-es verzióra. A folyamat szerencsére automatizálható (például Azure CLI segítségével).
IaC frissítés: Ha Terraformot vagy Bicep-et használsz, módosítsd a sablonokat az új struktúrának megfelelően.

A váltás nem jár leállással, ha megfelelően hajtják végre, de a kivezetési dátum után a v1-es konfigurációk működése nem garantált.

Hasznos link

Kritikus: Ez egy fontos változás, a szolgáltatás/funkció ezen a napon megszűnik vagy megváltozik. A zavartalan működéshez beavatkozás szükséges.