Sdílet prostřednictvím

Zabezpečení pro AKS

  • Článek

Tento článek vás provede aspekty zásad správného řízení zabezpečení služby Azure Kubernetes Service (AKS), které je potřeba zvážit před implementací jakéhokoli řešení.

Tento článek se zaměřuje na implementaci řešení pomocí Azure a opensourcového softwaru. Rozhodnutí, která provedete při vytváření cílové zóny na podnikové úrovni, můžou částečně předdefinovat zásady správného řízení. Principy zásad správného řízení najdete v tématu Zásady správného řízení a dodržování předpisů na podnikové úrovni.

Povrchy útoku

Při vytváření strategie zabezpečení pro clustery Kubernetes zvažte následující pět útoků:

  • Sestavení
  • Registr
  • Cluster
  • Uzel
  • Aplikace

Pro každou kategorii probereme hlavní rizika, která je potřeba vzít v úvahu, a protiopatření těchto rizik.

Sestavení zabezpečení

Zabezpečení sestavení se týká správného použití DevSecOps s imagemi kontejnerů.

Hlavní rizika

Špatná konfigurace image může vést k ohrožením zabezpečení kanálu. Můžete mít například kontejnery spuštěné s většími oprávněními, než potřebují. Kontejnery mohou být také nakonfigurované tak, aby umožňovaly určitý síťový přístup, což může ohrozit systém. Omezení povolených systémových volání na tato volání požadovaná pro bezpečné operace kontejnerů může zvýšit riziko z ohroženého kontejneru.

Další ohrožení zabezpečení může umožnit kontejneru získat přístup k citlivému adresáři hostitele nebo umožnit kontejnerům změnit umístění, která řídí základní funkci hostitele.

Neplánované kontejnery jsou v prostředí neplánované kontejnery. Mohou to být výsledky, které vývojáři testují svůj kód v testovacích prostředích. Tyto kontejnery možná neprošly důkladným prohledáváním chyb zabezpečení nebo byly správně nakonfigurované. Tato ohrožení zabezpečení můžou útočníkům otevřít vstupní bod.

Použití základníchich

Protiopatření rizik

Zabezpečení sestavení se týká implementace DevSecOps, která posune zabezpečení doleva a vyřeší většinu problémů, než začnou přesouvat kanál směrem dolů. Nejedná se o umístění veškerého vlastnictví na vývojáře, ale sdílení vlastnictví s operacemi. Vývojáři pak můžou zobrazit a opravit chyby zabezpečení a problémy s dodržováním předpisů, které můžou skutečně řešit.

Můžete vytvořit kanál, který prohledává a selže sestavení, protože má jednu nebo 10 kritických chyb zabezpečení. Lepším přístupem může být pohled na další vrstvu dolů. Můžete začít segmentovat bod odpovědnosti na základě stavu dodavatele.

Nastavte prahovou hodnotu ve vrstvě stavu ohrožení zabezpečení. Cokoli se stavem Open, Will not fix nebo Deferred pokračuje v poklesu kanálu, kde SecOps může přistupovat k riziku, jak to dělají dnes. Ohrožení zabezpečení se stavem dostupných oprav dodavatelů je něco, co může řešit vývojář. Použití období odkladu umožňuje vývojářům opravit chyby zabezpečení.

Spolu s posouzením ohrožení zabezpečení je posouzení dodržování předpisů. Například povolení spuštění image jako kořenového adresáře nebo vystavení protokolu SSH přeruší stav dodržování předpisů většiny podniků. Tento problém vyřešte během sestavování místo během nasazování.

Obvykle naskenujete image proti srovnávacímu testu Docker CIS. Pokud používáte tyto typy toků, nebudete vyrušovat vývoj tím, že zavedete nápravu zabezpečení, ale můžete zlepšit celkový stav zabezpečení podniku.

Použití nástroje, který tyto možnosti umožňuje, je velmi důležité k efektivní implementaci správné strategie pro váš podnik. Tradiční nástroje často nemůžou detekovat ohrožení zabezpečení v kontejnerech, což může vést k falešnému pocitu zabezpečení. K zajištění správného zabezpečení ekosystému kontejnerů jsou potřeba nástroje, které využívají přístup založený na kanálu a neměnnou a deklarativní povahu technologií kontejnerů.

Tyto nástroje by měly mít následující vlastnosti:

  • Integrace s celou životností imagí od začátku procesu sestavení do registru až po modul runtime.
  • Přehled o ohrožení zabezpečení ve všech vrstvách image, včetně základní vrstvy image, aplikačních architektur a vlastního softwaru.
  • Vynucení řízené zásadami se správnou úrovní členitosti, což vaší organizaci umožňuje vytvářet brány kvality v každé fázi procesů sestavení a nasazení.

Zabezpečení registru

Zabezpečení registru se týká:

  • Řízení odchylek od sestavení
  • Prevence nasdílení/stažení kontaminovaných obrázků.
  • Podepisování obrázků

Hlavní rizika

Obrázky často obsahují proprietární informace, včetně zdrojového kódu organizace. Pokud připojení k registrům nejsou správně zabezpečená, může obsah obrázku představovat rizika důvěrnosti jako závažná jako jakákoli jiná forma dat přenášených ve vaší organizaci. Zastaralé image s zastaralými verzemi v registru můžou zvýšit bezpečnostní rizika, pokud jsou omylem nasazené.

Další ohrožení zabezpečení může zahrnovat nedostatečná omezení ověřování a autorizace pro registry kontejnerů. Tyto registry můžou na obrázcích obsahovat citlivé proprietární prostředky.

Při vytváření a nasazení obsahu je distribuce tohoto obsahu jedním z mnoha vektorů útoku. Jak zajistíte, aby obsah připravený pro distribuci byl stejný obsah, který se doručil do zamýšleného koncového bodu?

Protiopatření rizik

Nastavte procesy nasazení, abyste zajistili, že vývojové nástroje, sítě a moduly runtime kontejnerů jsou připojené jenom k registrům přes šifrované kanály. Také se ujistěte, že obsah pochází z důvěryhodného zdroje. Omezení rizik při používání zastaralých imagí:

  • Odeberte nebezpečné a zranitelné image, které by se už neměly používat z registrů kontejnerů.
  • Vynucujte přístup k imagím pomocí neměnných názvů, které určují konkrétní verze obrázků, které se mají použít. Tuto konfiguraci můžete implementovat pomocí nejnovější značky nebo konkrétní verze imagí. Značka nezaručuje aktuálnost. Z tohoto důvodu umístěte proces, který zajistí, že orchestrátor Kubernetes používá nejnovější jedinečná čísla nebo že nejnovější značka představuje nejaktuálnější verze.

Přístup k registrům, které obsahují citlivé obrázky, by měl vyžadovat ověření a autorizaci. Veškerý přístup k zápisu by měl také vyžadovat ověření. Vaše zásada může například vývojářům umožnit nasdílení imagí jenom do konkrétních úložišť, za která zodpovídají.

Přístup k těmto registrům by měl být federovaný a využívat zásady přístupu na úrovni podniku. Kanál CI/CD můžete například nakonfigurovat tak, aby nasdílel image do úložišť až poté, co prošel posouzením dodržování předpisů a testy kontroly kvality kontroly ohrožení zabezpečení.

Registry kontejnerů se nyní považují za primární prostředky pro nasazení libovolného typu obsahu, nejen imagí kontejnerů. Každý cloud poskytuje registr s opensourcovými projekty a produkty dodavatelů, které jsou dostupné pro místní nebo privátní hostování v rámci poskytovatelů cloudu. Obsah se propaguje v rámci registrů a v rámci jejich počátečního sestavení až po produkční nasazení.

Jak můžete zajistit integritu obsahu, který se dostal do registru, je stejný obsah, který pochází z registru? Přijetí řešení podepisování imagí zajišťuje, že nasazení pocházejí pouze z důvěryhodných registrů a nasazují důvěryhodný obsah.

Zabezpečení clusteru

Zabezpečení clusteru se týká:

  • Ověřování a autorizace.
  • Zabezpečení sítě.
  • Ohrožení zabezpečení a správa dodržování předpisů.

Hlavní rizika

Někdy se může použít jeden cluster Kubernetes ke spouštění různých aplikací spravovaných různými týmy s různými požadavky na úroveň přístupu. Pokud je přístup poskytnut jednotlivcům bez omezení nebo pouze podle jejich potřeb, mohl by škodlivý nebo bezstarý uživatel ohrozit úlohy, ke kterým má přístup, a další prostředky v clusteru.

K dalšímu ohrožení zabezpečení může dojít, když vlastní uživatelský adresář clusteru spravuje autorizaci a ověřování. Adresář ověřování organizace je často důkladněji řízen. Vzhledem k tomu, že tyto účty jsou vysoce privilegované a častěji osamocené, zvyšuje se pravděpodobnost ohrožení účtu.

Tento scénář může vést k ohrožením zabezpečení v rámci celého systému nebo clusteru. Data uložená podle svazků kontejnerů se spravují orchestrátory, které musí mít přístup k datům bez ohledu na to, na kterém uzlu je hostovaný.

Tradiční síťové filtry můžou mít zaslepost zabezpečení kvůli překrytí sítě navržené k šifrování přenášených dat. Tento návrh ztěžuje monitorování provozu v rámci clusteru, takže ke sledování clusterů Kubernetes může být potřeba zvláštní ustanovení.

Provoz z různých aplikací, které sdílejí stejný cluster, může mít různé úrovně citlivosti, jako je veřejný web a interní aplikace s kritickými citlivými obchodními procesy. Sdílení stejné virtuální sítě v rámci clusteru může vést k ohrožení citlivých dat. Útočník může například použít sdílenou síť vystavenou internetu k útoku na interní aplikace.

Chraňte komponenty spuštěné v samotném clusteru před problémy s ohroženími zabezpečení a dodržováním předpisů. Ujistěte se, že používáte nejnovější možnou verzi Kubernetes, abyste využili výhod nápravy.

Protiopatření rizik

Přístup uživatelů clusteru Kubernetes by měl používat model přístupu s nejnižšími oprávněními. Udělte uživatelům přístup pouze k provádění konkrétních akcí na konkrétních hostitelích, kontejnerech a imagích, které jsou potřeba k provádění jejich úloh. Testovací členové týmu by měli mít omezený nebo žádný přístup k kontejnerům v produkčním prostředí. Uživatelské účty s přístupem na úrovni clusteru by se měly pečlivě kontrolovat a používat střídmě.

K zabezpečení přístupu k těmto účtům používejte silné metody ověřování, jako je vícefaktorové ověřování. Uživatelský adresář organizace by se měl používat ke správě clusterů prostřednictvím jednotného přihlašování, a ne uživatelských účtů specifických pro clustery, které nemusí mít stejnou úroveň zásad a ovládacích prvků.

Použijte metody šifrování, které umožňují kontejnerům správně přistupovat k datům bez ohledu na to, na čem jsou kontejnery spuštěné. Tyto nástroje pro šifrování by měly bránit neoprávněnému přístupu k datům jinými kontejnery i v rámci stejného uzlu, ke kterému by neměl mít přístup.

Nakonfigurujte clustery Kubernetes tak, aby oddělily síťový provoz do samostatných virtuálních sítí nebo podsítí podle úrovně citlivosti. Segmentace jednotlivých aplikací může být také možná, ale definování sítí podle úrovní citlivosti může stačit. Například virtuální sítě pro aplikace zaměřené na zákazníky oddělené od těch, které obsluhují interní aplikace s citlivým provozem, by se měly implementovat minimálně.

Pomocí taintů a tolerance můžete izolovat nasazení na konkrétní sady uzlů podle úrovní citlivosti. Vyhněte se hostování vysoce citlivých úloh ve stejném uzlu jako tyto úlohy s nižší citlivostí. Použití samostatných spravovaných clusterů je bezpečnější možností.

Segmentace kontejnerů podle účelu, citlivosti a stavu vlákna, aby poskytovaly dodatečnou ochranu citlivých úloh. Díky segmentování kontejnerů tímto způsobem je pro útočníka, který získal přístup k jednomu segmentu, obtížnější získat přístup k jiným segmentům. Tato konfigurace má přidanou výhodu zajištění zbytkových dat, jako jsou mezipaměti nebo připojení svazků, jsou izolované podle úrovně citlivosti.

Clustery Kubernetes by měly být nakonfigurované na:

  • Poskytněte zabezpečené prostředí pro aplikace, které na nich běží.
  • Zajistěte, aby se uzly bezpečně přidaly do clusteru.
  • Mít trvalé identity, které pomáhají zajistit zabezpečení v průběhu jejich životního cyklu.
  • Zadejte živé a přesné informace o stavu clusteru, včetně sítí a uzlů v něm.

Musí být snadný, aby byl ohrožený uzel izolovaný a odebraný z clusteru, aniž by to mělo vliv na výkon clusteru. AKS to usnadňuje.

Definujte standardy konfigurace modulu runtime kontejneru pro automatické zajištění dodržování předpisů. V Azure je mnoho zásad, které usnadňují tento proces a uživatelé můžou také vytvářet vlastní zásady. Pomocí funkcí zabezpečení Azure můžete průběžně vyhodnocovat nastavení konfigurace v celém prostředí a aktivně je vynucovat.

Automaticky se ujistěte, že se řeší ohrožení zabezpečení komponent Kubernetes. Pro vývoj, testování a produkci používejte samostatná prostředí s vlastními ovládacími prvky a řízením přístupu na základě role (RBAC) pro správu kontejnerů. Přidružte veškeré vytváření kontejneru k jednotlivým identitám uživatelů a mělo by se protokolovat pro auditování. Tato konfigurace pomáhá snížit riziko podvodných kontejnerů.

Zabezpečení uzlů

Zabezpečení uzlu se týká:

  • Ochrana za běhu
  • Ohrožení zabezpečení a správa dodržování předpisů.

Hlavní rizika

Pracovní uzel má privilegovaný přístup ke všem komponentám v uzlu. Útočníci můžou jako vstupní bod použít libovolnou službu přístupnou k síti, takže poskytnutí přístupu k hostiteli z více bodů může vážně zvýšit prostor pro útok. Čím větší prostor pro útok, tím větší je šance, že útočník získá přístup k uzlu a jeho operačnímu systému.

Také operační systémy specifické pro kontejnery, jako jsou operační systémy používané v uzlech AKS, mají menší prostor pro útoky, protože neobsahují knihovny, které umožňují normálním operačním systémům přímo spouštět databáze a webové servery. Použití sdíleného jádra vede k většímu prostoru pro útoky pro kontejnery běžící ve stejném prostředí než kontejnery v samostatných virtuálních počítačích. To platí i v případě, že se používají operační systémy specifické pro kontejnery běžící na uzlech AKS.

Hostitelské operační systémy poskytují základní systémové komponenty, které můžou mít ohrožení zabezpečení a riziko dodržování předpisů. Vzhledem k tomu, že se jedná o komponenty nízké úrovně, můžou jejich ohrožení zabezpečení a konfigurace ovlivnit hostování všech kontejnerů. AKS chrání uživatele tím, že zajišťuje, aby se o tato ohrožení zabezpečení postarala prostřednictvím pravidelných aktualizací operačního systému na uzlech spuštěných v AKS a stav dodržování předpisů pracovního uzlu se udržuje.

Nesprávná uživatelská přístupová práva můžou také vést k bezpečnostním rizikům, když se uživatelé přihlásí přímo k uzlům, aby mohli spravovat kontejnery, a ne prostřednictvím řídicí roviny AKS. Když se přihlásíte přímo, může uživateli umožnit provádět změny aplikací nad rámec těch, ke kterým by měl mít přístup.

Škodlivé kontejnery také můžou vést k manipulaci s operačním systémem operačního systému. Pokud je například kontejner povolený připojit citlivý adresář v hostitelském operačním systému, může tento kontejner provádět změny souborů. Změny můžou mít vliv na zabezpečení jiných kontejnerů spuštěných na hostiteli.

Protiopatření rizik

Omezte přístup k uzlu omezením přístupu přes SSH.

Použití operačního systému specifického pro kontejnery v uzlech AKS obvykle snižuje možnosti útoku, protože ostatní služby a funkce jsou zakázané. Mají také systémy souborů jen pro čtení a ve výchozím nastavení využívají další postupy posílení zabezpečení clusteru.

Platforma Azure automaticky používá opravy zabezpečení operačního systému na uzly s Linuxem a Windows na noční bázi. Pokud aktualizace zabezpečení operačního systému Linux vyžaduje restartování hostitele, automaticky se nerestartuje. AKS poskytuje mechanismy pro restartování, které použijí tyto konkrétní opravy.

Microsoft Defender pro servery se nevztahuje na uzly AKS s Linuxem a Windows, protože Microsoft spravuje operační systém. Pokud nejsou v předplatném, ve kterém je nasazená služba AKS, žádné jiné virtuální počítače, můžete bezpečně zakázat Microsoft Defender pro servery.

Pokud je prostředí nasazené, včetně doporučených zásad Azure v cílové zóně na podnikové úrovni, můžete nakonfigurovat vyloučení pro přiřazení zásad ve skupině pro správu, která automaticky povolí Microsoft Defender for Servers, aby nedocházelo k zbytečným nákladům.

Zabezpečení aplikací

Zabezpečení aplikací se týká:

  • Ochrana za běhu
  • Ohrožení zabezpečení a správa dodržování předpisů.

Hlavní rizika

Obrázky jsou soubory, které zahrnují všechny součásti potřebné ke spuštění aplikace. Když se k vytváření imagí používají nejnovější verze těchto komponent, můžou být v tuto chvíli bez známých ohrožení zabezpečení, ale můžou se rychle změnit.

Tyto soubory musíte udržovat aktuální s nejnovějšími verzemi, protože vývojáři balíčků pravidelně identifikují ohrožení zabezpečení. Aktualizace kontejneru můžete dále upstreamovat aktualizací imagí použitých k vytvoření kontejnerů, na rozdíl od tradičních aplikací, které se obvykle aktualizují v hostiteli.

Škodlivé soubory lze také vložit do image, která se pak dá použít k útoku na jiné kontejnery nebo součásti systému. Kontejnery třetích stran mohou být možným vektorem útoku. Konkrétní podrobnosti o nich můžou být neznámé a mohly by dojít k úniku dat. Kontejnery možná nebyly aktuální s požadovanými aktualizacemi zabezpečení.

Dalším vektorem útoku je použití vložených tajných kódů, jako jsou hesla a připojovací řetězec přímo v systému souborů obrázků. Tento postup může způsobit bezpečnostní riziko, protože každý, kdo má přístup k imagi, může získat přístup k tajným kódům.

V samotných aplikacích může docházet k chybám, jako jsou aplikace, které jsou zranitelné vůči skriptování mezi weby nebo injektáži SQL. Pokud chyby existují, může být toto ohrožení zabezpečení použito k povolení neoprávněného přístupu k citlivým informacím v jiných kontejnerech nebo dokonce hostitelském operačním systému.

Modul runtime kontejneru AKS usnadňuje monitorování ohrožení zabezpečení pomocí různých nástrojů zabezpečení dostupných v Azure. Další informace najdete v tématu Úvod do Programu Microsoft Defender pro Kubernetes.

Měli byste také řídit odchozí síťový provoz odesílaný do kontejnerů, abyste zajistili, že kontejnery nebudou moct odesílat provoz mezi sítěmi různých úrovní citlivosti, jako jsou prostředí hostující zabezpečená data nebo do internetu. Azure usnadňuje řízení pomocí různých funkcí zabezpečení sítě a AKS.

Plánovače Kubernetes se ve výchozím nastavení zaměřují na řízení škálování a maximalizaci hustoty úloh běžících na uzlech. Pody různých úrovní citlivosti můžou umístit do stejného uzlu jenom proto, že tento hostitel má nejvíce dostupných prostředků. Tento scénář může potenciálně vést k incidentům zabezpečení, když útočníci používají přístup k veřejným úlohám k útokům na kontejnery se spuštěnými citlivějšími procesy na stejném hostiteli. Napadený kontejner se může také použít ke kontrole sítě a vyhledání dalších ohrožení zabezpečení, která útočník může zneužít.

Protiopatření rizik

Nikdy neukládejte tajné kódy v kódu aplikace nebo v systémech souborů. Tajné kódy by měly být uložené v úložištích klíčů a podle potřeby by se měly poskytovat kontejnerům za běhu. AKS zajistí, že k nim mají přístup jenom kontejnery, které potřebují přístup k určitým klíčům, a že tyto tajné kódy se neuchovávají na disku. Azure Key Vault může například bezpečně ukládat tyto tajné kódy a podle potřeby je poskytnout clusteru AKS. Je také jednoduché zajistit, aby se tyto tajné kódy zašifrovaly jak v úložišti, tak při přenosu.

Vyhněte se používání nedůvěryhodných imagí a registrů a zajistěte, aby v clusterech běžely jenom image z důvěryhodných sad. Pro vícevrstevný přístup:

  • Centrálně můžete řídit, jaké image a registry jsou důvěryhodné.
  • Jednotlivé obrázky můžete samostatně identifikovat kryptografickým podpisem.
  • Nasaďte zásady, které zajistí, že všichni hostitelé spouštějí jenom image ze schválené sady.
  • Před spuštěním tyto podpisy ověřte.
  • Monitorujte a aktualizujte tyto image a registry, protože se mění ohrožení zabezpečení a požadavky na konfiguraci.

Profily zabezpečeného výpočetního prostředí by se měly použít k omezení kontejnerů a přidělovat je za běhu. Vlastní profily je možné vytvářet a předávat do modulů runtime kontejnerů, aby se jejich možnosti dále omezily. Minimálně se ujistěte, že se kontejnery spouštějí s výchozími profily. Zvažte použití vlastních, více omezených profilů pro kontejnery s vysoce rizikovými aplikacemi.

Nástroje můžou automaticky profilovat aplikace pomocí behaviorálního učení a detekovat anomálie. K detekci anomálií za běhu můžete použít řešení třetích stran. Anomálie můžou zahrnovat například tyto události:

  • Neplatné nebo neočekávané spuštění procesu nebo systémová volání.
  • Změny chráněných konfiguračních souborů a binárních souborů
  • Zapisuje se do neočekávaných umístění a typů souborů.
  • Vytvoření neočekávaných naslouchacích procesů sítě
  • Provoz odesílaný do neočekávaných síťových cílů
  • Úložiště a spouštění malwaru.

Microsoft Defender pro Kubernetes v současné době investuje do této oblasti.

Kontejnery by se měly spouštět s kořenovým systémem souborů v režimu jen pro čtení a izolovat zápisy do definovaných adresářů, které tyto nástroje můžou snadno monitorovat. Díky této konfiguraci jsou kontejnery odolnější vůči ohrožení zabezpečení, protože izolujete manipulaci s těmito konkrétními umístěními. Lze je snadno oddělit od zbytku aplikace.

Aspekty návrhu

AKS má několik rozhraní pro jiné služby Azure, jako je Microsoft Entra ID, Azure Storage a Azure Virtual Network. Používání těchto služeb vyžaduje zvláštní pozornost během fáze plánování. AKS také zvyšuje složitost, která vyžaduje, abyste zvážili použití stejných mechanismů a mechanismů dodržování předpisů a zásad správného řízení zabezpečení jako ve zbytku infrastruktury.

Tady jsou některé další aspekty návrhu pro zásady správného řízení zabezpečení a dodržování předpisů AKS:

  • Pokud vytvoříte cluster AKS v předplatném nasazeném podle osvědčených postupů cílové zóny na podnikové úrovni, seznamte se se zásadami Azure, které budou clustery dědit. Další informace najdete v tématu Zásady zahrnuté v referenčních implementacích cílových zón Azure.
  • Rozhodněte se, jestli má být řídicí rovina clusteru přístupná přes internet (doporučujeme omezení IP adres), která je výchozí, nebo pouze z vaší privátní sítě v Azure nebo v místním prostředí jako privátní cluster. Pokud vaše organizace používá osvědčené postupy cílové zóny na podnikové úrovni, skupina pro správu má přidruženou zásadu Azure Policy, Corp která vynutí, aby clustery byly soukromé. Další informace najdete v tématu Zásady zahrnuté v referenčních implementacích cílových zón Azure.
  • Pomocí integrovaného modulu zabezpečení AppArmor Pro Linux vyhodnoťte akce, které kontejnery můžou provádět, jako je čtení, zápis, spouštění nebo systémové funkce, jako jsou připojení systémů souborů. Například všechna předplatná mají zásady Azure, které brání podům ve všech clusterech AKS vytvářet privilegované kontejnery. Další informace najdete v tématu Zásady zahrnuté v referenčních implementacích cílových zón Azure.
  • Vyhodnoťte použití ( seccomp secure computing) na úrovni procesu, abyste omezili volání procesů, která mohou kontejnery provádět. Azure Policy se například použila jako součást obecné implementace cílové zóny na podnikové úrovni ve skupině pro správu cílových zón, aby se zabránilo eskalaci oprávnění kontejneru do kořenového adresáře seccomp prostřednictvím zásad Azure pro Kubernetes.
  • Rozhodněte se, jestli je váš registr kontejneru přístupný přes internet, nebo jenom v rámci konkrétní virtuální sítě. Zakázání přístupu k internetu v registru kontejneru může mít negativní vliv na jiné systémy, které při přístupu k němu spoléhají na veřejné připojení. Mezi příklady patří kanály kontinuální integrace nebo Microsoft Defender pro kontrolu obrázků. Další informace najdete v tématu Privátní připojení k registru kontejneru pomocí služby Azure Private Link.
  • Rozhodněte se, jestli se váš privátní registr kontejneru sdílí napříč několika cílovými zónami, nebo jestli do každého předplatného cílové zóny nasadíte vyhrazený registr kontejneru.
  • Zvažte použití řešení zabezpečení, jako je Microsoft Defender pro Kubernetes pro detekci hrozeb.
  • Zvažte kontrolu ohrožení zabezpečení imagí kontejnerů.
  • Pokud neexistují žádné virtuální počítače bez AKS, zvažte zakázání programu Microsoft Defender pro servery v předplatném AKS, abyste se vyhnuli zbytečným nákladům.

Doporučení k návrhu

Důležité

Kontrola imagí v programu Microsoft Defender for Cloud není kompatibilní s koncovými body služby Container Registry. Další informace najdete v tématu Privátní připojení k registru kontejneru pomocí služby Private Link.