Megosztás a következőn keresztül:

Alkalmazások és fürtök biztonsági koncepciói az Azure Kubernetes Szolgáltatásban (AKS)

Az konténerbiztonság védi a teljes végpontok közötti csővezetékeket az összeállítástól kezdve a Azure Kubernetes Service (AKS)-ben futó alkalmazásfolyamatokig.

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. Az Azure a következő összetevőket tartalmazza: Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, hálózati biztonsági csoportok és klaszterfrissítések. AKS ötvözi ezeket a biztonsági összetevőket, hogy:

  • Biztosítson egy teljes hitelesítési és engedélyezési folyamatot.
  • Alkalmazza az AKS Beépített Azure Szabályzatot az alkalmazásai biztonságának megőrzése érdekében.
  • Végponttól végpontig terjedő betekintés az alkalmazásod fejlesztésétől a használatáig a Microsoft Defender for Containers segítségével.
  • 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.

Biztonság kiépítése

Mint az Ellátási Lánc belépési pontja, fontos a képfelépítések statikus elemzésének elvégzése, mielőtt továbbítva lennének a folyamat során. 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 mesterek komponensei a menedzselt szolgáltatás részét képezik, amelyet a Microsoft biztosít, kezel és tart karban. Minden AKS klaszterhez tartozik saját, egybérlős, dedikált Kubernetes mester, amely biztosítja az API Szervert, a Ütemezőt stb. További információért lásd: Azure Kubernetes Service sebezhetőségkezelése.

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.

A hozzáférést az API kiszolgálóhoz Kubernetes szerepalapú hozzáférés-vezérléssel (Kubernetes RBAC) és Azure RBAC-kal tudja szabályozni. További információért lásd: A Microsoft Entra integrációja az AKS-sel.

Csomópont biztonság

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

  • A Linux csomópontok optimalizált Ubuntu vagy Azure Linux verziókat futtatnak.
  • A Windows Server csomópontok az optimalizált Windows Server 2022 kiadást futtatják a containerd konténer futtatókörnyezet használatával.

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 node poolok a containerd-t használják alapértelmezett konténer futtatási környezetként. További információért lásd: Add a Windows Server node pool with 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.

További információkért a Linux és Windows munkavégző csomópontok biztonsági frissítési folyamatáról, lásd Biztonsági javító csomópontok.

Az AKS klaszterek Azure Generation 2 VM-eket futtatása támogatja a Trusted Launch-t, amely fejlett és tartós támadási technikák ellen védi, olyan technológiák kombinálásával, amelyek önállóan engedélyezhetők, mint például a biztonságos indítás és a megbízható platform modul virtualizált verziója (vTPM). 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.

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ára a csomópontok az Azure kezelt meghajtókat használják. A legtöbb VM csomópontmérethez az Azure Managed Disks Premium lemezek, amelyeket nagy teljesítményű SSD-k támogatnak. A kezelt lemezeken tárolt adatok az Azure platformon belül automatikusan titkosítva vannak nyugalmi állapotban. A redundancia javítása érdekében az Azure Managed Disks biztonságosan replikálódik az Azure adatközponton belül.

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. Az ilyen munkaterhelésekhez az Azure a következőket 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 az Azure Host Fabrictől, a gazdagép operációs rendszerétől és a hipervizortól. Egyetlen ügyfél számára elkötelezettek. 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 konténereket más konténercsoportoktól/fürtöktől, valamint a VM csomópont operációs rendszerének 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

Az on-premises hálózatokhoz való csatlakozás és biztonság érdekében telepítheti AKS fürtjét meglévő Azure virtuális hálózati alhálózatokba. Ezek a virtuális hálózatok az Azure Site-to-Site VPN vagy az Express Route használatával csatlakoznak vissza a helyszíni hálózatához. 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

Az Azure a hálózati biztonsági csoportszabályokat használja a virtuális hálózati forgalom szűrésére. 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 klaszteréhez (használva akár az Azure CNI-t, akár a Kubenetet), ne módosítsa az AKS által kezelt 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 a Microsoft Defender for Containers használatát a podokon futó alkalmazások elleni kibertámadások észleléséhez és korlátozásához. 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 bevált gyakorlatként a beépített Linux biztonsági funkciók, például az AppArmor és a seccomp használata a tárolók biztonságos hozzáféréséhez az erőforrásokhoz.

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: