Úvod
Orchestrační nástroje, jako je Kubernetes, zavedly bezprecedentní úroveň odolnosti a všestrannosti při nasazení a správě softwaru. Zaměřili se také na nedostatky současného bezpečnostního prostředí.
Dispergovaná architektura Kubernetes nám poskytuje několik dalších vrstev. Můžeme je použít k vylepšení a vybudování na stávajících nastaveních zabezpečení. Pokud tyto vrstvy nakonfigurujete správně, dokážou izolovat jakoukoli bezpečnostní hrozbu dříve, než propukne z místa původu.
Tento článek se zaměřuje na opatření, která můžete přijmout ke zlepšení celkového zabezpečení clusteru Kubernetes.
1. Povolit Role-Based Access Control (RBAC)
Složitost systému běžícího na více zařízeních s mnoha vzájemně propojenými mikroslužbami spravovanými stovkami jednotlivců a utilit je logistickou noční můrou.
Uplatněte přísnou kontrolu nad oprávněními udělenými uživatelům. Kubernetes je zastáncem řízení přístupu založeného na rolích (RBAC) metoda. Metoda řízení přístupu na základě rolí znamená, že žádný uživatel nemá více oprávnění, než potřebuje efektivně plnit své úkoly. Kubernetes je o automatizaci a RBAC používá skupinu API k řízení autorizačních rozhodnutí prostřednictvím Kubernetes API.
Od verze Kubernetes 1.8 je režim RBAC stabilní a je podporován rbac.authorization.k8s.io/v1 API. Povolte RBAC spuštěním serveru API pomocí následujícího příkazu:
--authorization-mode=RBACKubernetes má sadu předdefinovaných rolí pro lidské uživatele i komponenty, jako jsou aplikace, ovladače a uzly. Těchto předdefinovaných rolí je mnoho a nabízejí rozumnou výchozí úroveň samostatných rolí pro nejběžnější úkoly.
2. Udržujte svá tajemství v tajnosti
V Kubernetes je Secret malý objekt, který obsahuje citlivá data, jako je heslo nebo token.
I když modul nemá přístup k tajemstvím jiného modulu, je důležité udržet tajemství oddělené od obrázku nebo modulu. Jinak by k tajemství měl přístup také kdokoli s přístupem k obrázku. V tomto ohledu jsou obzvláště zranitelné komplexní aplikace, které obsluhují více procesů a mají veřejný přístup.
Přiřazení procesů k různým kontejnerům
Každý kontejner v podu musí vyžadovat tajný objem ve svém objemu. Snižte riziko odhalení tajemství rozdělením procesů do samostatných kontejnerů. Použijte front-endový kontejner, který komunikuje s uživateli, ale nevidí soukromý klíč.
Doplňte tento kontejner kontejnerem signer, který může vidět soukromý klíč a reagovat na jednoduché požadavky na podepisování z front-endu. Tento rozdělený přístup nutí útočníka provést řadu složitých akcí ve snaze narušit vaše bezpečnostní opatření.
3. Omezte provoz z pod-do-pod pomocí síťových zásad Kubernetes
Jedná se o doporučený postup pro zabezpečení Kubernetes zavést protokol zabezpečení TLS na každé úrovni kanálu nasazení aplikace. Je však také nezbytné zabezpečit jednotlivé prvky, které tvoří cluster, a prvky, které řídí přístup ke clusteru.
Moduly ve výchozím nastavení přijímají provoz z jakéhokoli zdroje. Když definujete Zásady sítě , nastavíte konkrétní pravidla pro to, jak pody komunikují v rámci clusteru a s externími zdroji.
Síťové zásady nejsou v rozporu, ale jsou aditivní. Definování síťové zásady v oboru názvů znamená, že modul odmítne jakékoli připojení, které tato politika nepovoluje, čímž se modul účinně izoluje. Modul je omezen na to, co je schváleno kombinací více síťových zásad.
4. Vylepšete zabezpečení podu
Zabezpečení jádra pomocí AppArmor nebo SELinux
Kontejnery sdílejí stejné jádro, takže je nutné použít další nástroje ke zlepšení izolace kontejnerů. Bezpečnostní moduly, jako je AppArmor a systémy, které prosazují zásady řízení přístupu, jako je SELinux , omezují uživatelské programy a systémové služby. Používají se také k odepření přístupu k souborům a omezení síťových zdrojů.
AppArmor omezuje sadu zdrojů dostupných pro kontejner v rámci systému. Každý profil může běžet buď v vynucování režim, který blokuje přístup k nepovoleným zdrojům nebo stížnosti režim, který pouze hlásí porušení. Včasné hlášení potenciálních problémů výrazně zlepšuje možnosti protokolování a auditu vašich systémů.
SELinux spravuje alokaci zdrojů nezávisle na obecném linuxovém ACM (Access Control Mechanism). Nerozpozná superuživatele (root) a není závislý na binárních souborech setuid/setgid.
Zabezpečení systému bez SELinuxu závisí na správné konfiguraci privilegovaných aplikací a samotného jádra. Nesprávná konfigurace v těchto oblastech může ohrozit celý systém. Bezpečnost systému založeného na jádře SELinux závisí na správnosti jádra a jeho konfiguraci bezpečnostní politiky.
Útoky stále představují významnou hrozbu. Se SELinuxem však jednotlivé uživatelské programy a systémoví démoni nemusí nutně ohrozit bezpečnost celého systému.
Poskvrny a tolerance
Kubernetes poskytuje možnost vytvořit předdefinovaná pravidla, když systém přiřazuje nové pody k uzlům.
Jako nástroj pro orchestraci má Kubernetes tendenci spouštět moduly na nejúčinnějším místě v clusteru, tedy na místě s nejmenší zátěží. Umístění lusků je možné vyladit definováním skvrn a tolerancí.
Taints umožňují uzlům „odmítnout“ modul nebo sadu modulů na základě předem definovaných pravidel. Na druhou stranu, tolerance jsou aplikovány na úrovni modulu a umožňují modulům naplánovat na uzly s odpovídajícími Tainty (klávesy a efekty jsou stejné).
Poskvrny a tolerance by měly být používány v tandemu, aby se zajistilo, že lusky nebudou naplánovány na nevhodné uzly.
Jmenné prostory
Kubernetes nemá mechanismus, který by poskytoval zabezpečení napříč jmennými prostory. Omezte používání jmenných prostorů jako bezpečnostní funkce v rámci důvěryhodných domén a pro interní účely. Nepoužívejte jmenné prostory, když chcete uživateli clusteru Kubernetes odepřít přístup k jakémukoli z prostředků jiných jmenných prostorů.
watch a list požadavky umožňují klientům prohlížet hodnoty všech tajných klíčů, které jsou v daném jmenném prostoru. K implementaci těchto požadavků by měly mít oprávnění pouze ty nejprivilegovanější komponenty na systémové úrovni.
5. Průběžné aktualizace Kubernetes
Stalo se nemožné sledovat všechny potenciální útočné vektory. Tato skutečnost je nešťastná, protože není nic důležitějšího než být si vědom potenciálních hrozeb. Nejlepší obranou je ujistit se, že používáte nejnovější dostupnou verzi Kubernetes.
Existuje několik technik, jako jsou průběžné aktualizace a migrace fondu uzlů, které vám umožňují dokončit aktualizaci s minimálním přerušením a prostojem.
6. Definujte zásady auditu
Protokolování auditu zaznamenává časovou osu událostí, ke kterým dochází v clusteru Kubernetes. Sledováním akcí provedených uživateli a rozhraním Kubernetes API mohou administrátoři analyzovat řetězec událostí, které vedly k potenciálnímu problému.
Kubernetes vám umožňuje vyladit zásady auditu definováním toho, jak často jsou události protokolovány, zda mají být vydávány výstrahy a postup pro ukončení dotčených modulů.
Pravidelně používejte protokolování auditu, abyste zajistili, že váš systém bude aktuální a že hrozby zůstanou pod kartami. Nasazení založené na kontejnerech přidává do procesu auditu další rozměr. Porovnání mezi původním obrázkem a obrázkem běžícím v kontejneru lze efektivně použít ke zjištění, zda nějaké nesrovnalosti mohou vést k bezpečnostním obavám. Ujistěte se, že verze vašeho softwaru vždy obsahují nejnovější bezpečnostní záplaty.