Biztonsági fogalmak alkalmazásokhoz és fürtökhöz az Azure Kubernetes Szolgáltatásban (AKS)

A tárolóbiztonság védi a teljes teljes folyamatot a buildeléstől a Azure Kubernetes Service (AKS) futó alkalmazás-számítási feladatokig.

A biztonságos ellátási lánc tartalmazza a build környezetet és a regisztert.

A Kubernetes biztonsági elemeket tartalmaz, például csomagbiztonsági szabványokat és titkokat. Azure olyan összetevőket tartalmaz, mint a Active Directory, a tárolók Microsoft Defender, a Azure Policy, a Azure Key Vault, a hálózati biztonsági csoportok és a konvenciós fürtfrissítések. AKS ötvözi ezeket a biztonsági összetevőket, hogy:

  • Biztosítson egy teljes hitelesítési és engedélyezési folyamatot.
  • Az AKS beépített Azure Policy alkalmazása az alkalmazások biztonságának érdekében.
  • Teljes körű betekintés a build folyamattól az alkalmazáson keresztül a Microsoft Defender for Containers használatával.
  • Tartsa naprakészen az AKS fürtjét a legújabb operációs rendszer biztonsági frissítésekkel és Kubernetes kiadásokkal.
  • Biztosítsa a podok forgalmának biztonságát és a hozzáférést az érzékeny hitelesítő adatokhoz.

Ez a cikk bemutatja az AKS-ben az alkalmazásait védő alapvető fogalmakat.

Fontos

2025. november 30-tól kezdve az Azure Kubernetes Service (AKS) már nem támogatja és nem biztosít biztonsági frissítéseket az Azure Linux 2.0-s verziójához. Az Azure Linux 2.0 csomópont képfájlja be van fagyasztva a 202512.06.0 kiadás verziónál. 2026. március 31-től a rendszer eltávolítja a csomópontrendszerképeket, és nem tudja skálázni a csomópontkészleteket. Migráljon támogatott Azure Linux-verzióra azáltal, hogy frissíti a csomópontkészleteket egy támogatott Kubernetes-verzióra vagy migrál az osSku AzureLinux3 verzióra. További információkért lásd a GitHub nyugdíjazási issue-t és az Azure frissítések nyugdíjazási bejelentését. Ha értesülni szeretne a bejelentésekről és frissítésekről, kövesse a AKS kibocsátási megjegyzéseit.

Biztonság kiépítése

Az ellátási lánc belépési pontjaként fontos, hogy statikus elemzést végezzen a rendszerkép-buildekről, mielőtt előléptetné őket a folyamaton. Ez magában foglalja a sebezhetőségi és megfelelőségi értékelést. Nem arról van szó, hogy ne sikerüljön egy build csak azért, mert sebezhetősége van, mivel ez akadályozná a fejlesztést. Arról van szó, hogy a Vendor Status alapján szegmentáljunk azokra a sebezhetőségekre, amelyekkel a fejlesztő csapatok foglalkozhatnak. Használja a türelmi időszakokat is, hogy a fejlesztőknek legyen idejük a azonosított problémák javítására.

A nyilvántartás biztonsága

A kép sebezhetőségi állapotának felmérése a rendszerleíróban kimutatja az eltérést, és azokat a képeket is kiszűri, amelyek nem a build környezetéből származnak. Használja a Notary V2-t, hogy aláírásokat csatoljon a képeihez, ezzel biztosítva, hogy a telepítések megbízható helyről származnak.

Klaszter biztonság

Az AKS-ben a Kubernetes fő összetevői a Microsoft által biztosított, felügyelt és karbantartott felügyelt szolgáltatás részét képezik. Minden AKS-fürt saját egybérlős, dedikált Kubernetes-főkiszolgálóval rendelkezik, amely biztosítja az API Servert, a Schedulert stb. További információ: Vulnerability management for Azure Kubernetes Service.

Alapértelmezés szerint a Kubernetes API szerver egy nyilvános IP címet és egy teljesen minősített domain nevet (FQDN) használ. Korlátozhatja a hozzáférést az API szerver végponthoz a engedélyezett IP tartományok használatával. Ezenkívül létrehozhat egy teljesen privát klasztert az API szerver hozzáférésének korlátozása érdekében a virtuális hálózatában.

Az API-kiszolgálóhoz való hozzáférést Kubernetes szerepköralapú hozzáférés-vezérléssel (Kubernetes RBAC) és Azure RBAC-vel szabályozhatja. További információ: Microsoft Entra integráció az AKS-sel.

Csomópont biztonság

Az AKS-csomópontok Azure virtuális gépek, amelyeket Ön kezel és tart karban.

  • A Linux-csomópontok az Ubuntu vagy Azure Linux optimalizált verzióit futtatják.
  • Windows Server csomópontok egy optimalizált Windows Server kiadást futtatnak a containerd tároló futtatókörnyezetével.

Amikor egy AKS klaszter létrehozva vagy kibővítve van, a csomópontok automatikusan telepítve vannak a legfrissebb operációs rendszer biztonsági frissítésekkel és konfigurációkkal.

Megjegyzés

AKS klaszterek futása:

  • Kubernetes 1.19-es és újabb verziók - A Linux csomópontcsoportok a containerd-t használják, mint konténer futásidejű környezetet. Windows Server 2019 és Windows Server 2022 csomópontkészletek tároló-futtatókörnyezetként containerd használnak. További információ: A Windows Server csomópontkészlet hozzáadása containerd.
  • A Kubernetes 1.19-es és korábbi verzióiban - a Linux node készletek a Docker-t használják konténerfutás-ideként.

A Linux és Windows feldolgozó csomópontok biztonsági frissítési folyamatával kapcsolatos további információkért lásd: Security patching nodes.

A Azure 2. generációs virtuális gépeket futtató AKS-fürtök támogatják a Trusted Launch. Ez a funkció védelmet nyújt a fejlett és állandó támadási technikák ellen az önállóan engedélyezhető technológiák, például a biztonságos rendszerindítás és a megbízható platformmodul (vTPM) virtualizált verziójának kombinálásával. Adminisztrátorok telepíthetik az AKS munkavégző csomópontokat ellenőrzött és aláírt rendszerbetöltőkkel, operációs rendszer magokkal és meghajtókkal, az alatta lévő virtuális gép teljes rendszerindítási láncának integritásának biztosítása érdekében.

Tárolóra és biztonságra optimalizált operációs rendszer beállításai

Az AKS két új optimalizált Linux OPERÁCIÓS-beállítás támogatását adta ki. Azure Linux OS Guard (előzetes verzió) a Microsoft által létrehozott és az Azure-hoz optimalizált. Az OS Guard Azure Linuxra épül, speciális konfigurációval, amely biztonsági optimalizálással támogatja a tárolóalapú számítási feladatokat. A Flatcar Container Linux for AKS (előzetes verzió) egy CNCF-alapú, gyártósemleges tárolóoptimalizált, nem módosítható operációs rendszer, amely leginkább többfelhős és helyszíni környezetekben való futtatásra alkalmas. Ezek az operációsrendszer-beállítások nagyobb biztonságot nyújtanak más Linux operációs rendszerekhez képest, például:

  • A Linux OS Guard Azure és a Flatcar Container Linux for AKS egyaránt rendelkezik olyan nem módosítható operációs rendszerrel, amelyet futásidőben nem lehet módosítani. Minden operációsrendszer-bináris fájl, kódtár és statikus konfiguráció írásvédett, és a bit-for-bit integritás gyakran kriptográfiai védelem alatt áll. Ezek a speciális célú operációs rendszerek önálló rendszerképekként vannak szállítva, és mindenféle csomagkezelés vagy más hagyományos eszköz nélkül érkeznek az operációs rendszer módosítására. A felhasználói számítási feladatok elszigetelt környezetekben, például tárolókban futnak, elkülönítve az operációs rendszertől.
  • Az Azure Linux OS Guard és az AKS-hez készült Flatcar Container Linux egyaránt a SELinuxot használja a kötelező hozzáférés-vezérléshez.
  • Azure Linux OS Guard kényszeríti a FIPS és Trusted Launch engedélyezését, amely jobb megfelelőséget és védelmet biztosít a fejlett és állandó támadások ellen a megbízható platformmodul (vTPM) biztonságos rendszerindítási és virtualizált verziójának kombinálásával.

Amikor eldönti, hogy melyik tárolóoptimalizált operációsrendszer-beállításokat használja, az AKS a következőket javasolja:

  • Az AKS-hez készült Flatcar Container Linux (előzetes verzió) akkor használható, ha szállítói semleges, nem módosítható operációs rendszert keres felhők közötti támogatással.
  • Használja a Azure Linux OS Guard (előzetes verzió) ha vállalati használatra kész, nem módosítható operációs rendszert keres, amelyet Microsoft javasol.
  • Használja az Ubuntu-t , ha egy gyártósemleges, általános célú operációs rendszert keres felhők közötti támogatással.
  • A Azure Linux használata, ha a Microsoft által ajánlott, nagyvállalati használatra kész, általános célú operációs rendszert keres.

Egy táblázat képernyőképe, amely összehasonlítja az optimalizált operációs rendszer opciókat, mint például az AKS-hez készült Flatcar Container Linux és Azure Linux OS Guard, az általános célú operációs rendszer opciókkal, mint az Ubuntu és az Azure Linux.

Csomópont hitelesítés

A "Node" engedélyezés egy speciális célú engedélyezési mód, amely kifejezetten a kubelet API kérések engedélyezésére szolgál, hogy megvédje az East-West támadások ellen. A csomópont jogosultsági hozzárendelés alapértelmezetten engedélyezve van az AKS 1.24+ klaszterekben.

Csomópont telepítése

A csomópontok egy privát virtuális hálózati alhálózatra vannak telepítve, és nincs hozzárendelve nyilvános IP-cím. Hibaelhárítási és irányítási célokra az SSH alapértelmezés szerint engedélyezve van, és csak a belső IP-címen keresztül érhető el. Az SSH letiltása a klaszter vagy a csomópont-tároló létrehozása során, illetve egy meglévő klaszter vagy csomópont-tároló esetében jelenleg előzetes verzióban érhető el. További információt az SSH-hozzáférés kezelése című témakörben talál.

Csomópont tárolás

A tárolás biztosításához a csomópontok Azure Managed Disks használnak. A legtöbb virtuálisgép-csomópontméret esetében a Azure Managed Disks prémium szintű lemezek, amelyek nagy teljesítményű SSD-k által támogatottak. A felügyelt lemezeken tárolt adatok automatikusan titkosítva lesznek a Azure platformon belül. Az redundancia javítása érdekében az Azure Managed Disks biztonságosan replikálva van az Azure adatközpontban.

Ellenséges több-bérlős terhelések

A Kubernetes-környezetek jelenleg nem biztonságosak az ellenséges, több-bérlős használathoz. Az extra biztonsági funkciók, mint például a Pod Security Policies vagy a Kubernetes RBAC a csomópontokhoz, hatékonyan blokkolják a kihasználási lehetőségeket. Az ellenséges, több bérlős munkaterhelések futtatása során a valódi biztonság érdekében csak a hipervizorban bízzon. A Kubernetes biztonsági tartománya az egész klaszter lesz, nem egy egyedi csomópont.

Az ilyen típusú ellenséges, több bérlő által használt számítási feladatokhoz javasolt fizikailag izolált fürtöket használni. További információkért a munkaterhelések elkülönítésének módjairól tekintse meg az AKS klaszter izolációjának legjobb gyakorlatai című dokumentumot.

Számítási izoláció

A megfelelőségi vagy szabályozási követelmények miatt bizonyos munkaterhelések esetén más ügyfelek munkaterheléseitől való nagy fokú elszigeteltségre lehet szükség. Ezekhez a számítási feladatokhoz a Azure a következőt biztosítja:

  • Környezet izolált konténerek, amelyeket ügynökcsomópontokként használnak egy AKS klaszterben. Ezek a tárolók teljesen el vannak különítve egy adott hardvertípushoz, és elkülönítve vannak a Azure gazdagéphálótól, a gazdagép operációs rendszerétől és a hipervizortól. Egyetlen ügyfélnek vannak szentelve. Válasszon egyik izolált VM méretet a csomópont méretként AKS-köteg létrehozásakor vagy csomópontcsoport hozzáadása esetén.
  • Bizalmas Konténerek (előzetes verzió), alapja a Kata Bizalmas Konténerek is, titkosítja a konténer memóriáját és megakadályozza, hogy a számítás során a memória adatot tiszta, olvasható formátumban jelenjen meg vagy manipulálják. Segít elkülöníteni a tárolókat más tárolócsoportoktól/podoktól és a virtuálisgép-csomópont operációs rendszer kernelétől. A Confidential Containers (előzetes verzió) hardver alapú memória titkosítást (SEV-SNP) használ.
  • Pod Sandboxing (előnézet) egy izolációs határt biztosít a konténeralkalmazás és a konténer gazda megosztott kernelje, valamint számítási erőforrásai (CPU, memória és hálózat) között.

Hálózati biztonság

A helyszíni hálózatokkal való kapcsolat és biztonság érdekében üzembe helyezheti az AKS-fürtöt a meglévő Azure virtuális hálózati alhálózatokon. Ezek a virtuális hálózatok Azure helyek közötti VPN vagy Express Route használatával csatlakoznak a helyszíni hálózathoz. Határozzon meg Kubernetes belépési vezérlőket privát, belső IP-címekkel, hogy korlátozza a szolgáltatások hozzáférését a belső hálózati kapcsolathoz.

Azure hálózati biztonsági csoportok

A virtuális hálózati forgalom szűréséhez Azure hálózati biztonsági csoportszabályokat használ. Ezek a szabályok határozzák meg az engedélyezett vagy megtagadott hozzáférést biztosító forrás- és cél IP-tartományokat, portokat és protokollokat az erőforrásokhoz. Alapértelmezett szabályok úgy vannak létrehozva, hogy lehetővé tegyék a TLS forgalmat a Kubernetes API szerverhez. Szolgáltatásokat hoz létre terheléselosztókkal, port leképezésekkel vagy belépési útvonalakkal. AKS automatikusan módosítja a hálózati biztonsági csoportot a forgalom áramlásához.

Ha saját alhálózatot biztosít az AKS-fürthöz (akár Azure CNI-t, akár Kubenetet használ), ne módosítsa az AKS által felügyelt NIC-szintű hálózati biztonsági csoportot. Ehelyett hozzon létre több alhálózati szintű hálózati biztonsági csoportot a forgalom irányának módosításához. Győződjön meg róla, hogy nem zavarják az olyan szükséges forgalmat, amely a klaszter kezelésére szolgál, mint például a terheléselosztó elérése, a kontroll síkkal való kommunikáció, vagy az egress.

Kubernetes hálózati szabályzat

Az AKS támogatja a Kubernetes hálózati szabályzatokat a klaszteredben lévő podok közötti hálózati forgalom korlátozásához. Hálózati szabályzatokkal engedélyezheti vagy megtagadhatja a klaszteren belüli specifikus hálózati útvonalakat névterek és címkeválasztók alapján.

Alkalmazásbiztonság

Az AKS-en futó podok védelméhez fontolja meg Microsoft Defender tárolókhoz a podokon futó alkalmazások elleni kibertámadások észlelését és korlátozását. Végezzen folyamatos szkennelést az alkalmazás sebezhetőségi állapotának eltéréseinek észleléséhez, és implementáljon egy "kék/zöld/kanári" folyamatot a sebezhető képek javítására és cseréjére.

Tárolók erőforrásokhoz való hozzáférésének biztonságossá tétele

Ugyanúgy, ahogyan a felhasználóknak vagy csoportoknak csak a szükséges minimális jogosultságokat kell megadni, korlátozni kell a konténereket is kizárólag a szükséges műveletekre és folyamatokra. A támadás kockázatának minimalizálása érdekében kerülje az eszkalált jogosultságokat vagy gyökérhozzáférést igénylő alkalmazások és tárolók konfigurálását. Ajánlott eljárásként ajánlott a linuxos beépített biztonsági funkciók, például az AppArmor és a seccomphasználata a tároló erőforrásokhoz való hozzáférésének védelme érdekében.

A Kubernetes titkos kódjai

Kubernetes Secret segítségével érzékeny adatokat, például hozzáférési hitelesítő adatokat vagy kulcsokat lehet befecskendezni a podokba.

  1. Kubernetes API használatával hozzon létre egy Secret-et.
  2. Definiálja a podot vagy a telepítést, és kérjen egy konkrét Secretet.
    • Titkok csak azoknak a csomópontoknak kerülnek átadásra, ahol van ütemezett tároló, amely azt igényli.
    • A titok a tmpfs-ben van tárolva, nem íródik lemezre.
  3. Ha törli az utolsó podot egy csomóponton, amelynek szüksége van egy Secretre, a Secret törlődik a csomópont tmpfs-jéből.
    • A titkok egy adott névtérben tárolódnak, és csak a ugyanabban a névtérben lévő podokból érhetők el.

A "Secrets" használata csökkenti a pod vagy szolgáltatás YAML-manifesztjében meghatározott érzékeny információkat. Inkább a Kubernetes API Szerverben tárolt Titkot kérheti le a YAML manifeszt részeként. Ez a megközelítés csak a konkrét pod számára biztosít hozzáférést a titokhoz.

Megjegyzés

A nyers titkos manifeszt fájlok a titkos adatokat base64 formátumban tartalmazzák. További információért lásd a hivatalos dokumentációt. Kezeld ezeket a fájlokat bizalmas információként, és soha ne helyezd el őket a verziókezelőben.

A Kubernetes titkok az etcd nevű disztribuált kulcs-érték tárolóban vannak tárolva. Az AKS lehetővé teszi az etcd-ben tárolt titkok nyugalmi állapotú titkosítását az ügyfél által kezelt kulcsok használatával.

Következő lépések

Ahhoz, hogy elkezdje az AKS klaszterei biztonságának növelését, tekintse meg a AKS klaszter frissítése útmutatót.

Kapcsolódó bevált gyakorlatokért lásd az AKS fürtök biztonsági mentésével és frissítéseivel kapcsolatos bevált gyakorlatokat és az AKS podok biztonságával kapcsolatos bevált gyakorlatokat.

További információért a Kubernetes és AKS alapfogalmakról lásd:

  • Last updated on