Zásady zabezpečení pro důvěrné kontejnery ve službě Azure Kubernetes Service
Jak je popsáno v konsorciu Důvěrné výpočetní prostředí (CCC), "Důvěrné výpočetní prostředí je ochrana dat, která se používají, provedením výpočtů v hardwarově ověřeném důvěryhodném spouštěcím prostředí (TEE)." Důvěrné kontejnery AKS jsou navržené tak, aby chránily data podů Kubernetes, která se používají před neoprávněným přístupem mimo tyto pody. Každý pod se spouští na virtuálním počítači utility (UVM) chráněném procesorem AMD SEV-SNP TEE zašifrováním dat, která se používají, a zabrání přístupu k datům hostitelským operačním systémem (OS). Inženýři Microsoftu spolupracovali s opensourcovými komunitami Důvěrné kontejnery (CoCo) a Kata Containers na návrhu a implementaci důvěrných kontejnerů.
Přehled zásad zabezpečení
Jednou z hlavních komponent architektury systému Kata Containers je agent Kata. Pokud k implementaci důvěrných kontejnerů používáte Kata Containers, agent se spustí uvnitř hardwarového TEE, a proto je součástí důvěryhodného výpočetního základu podu (TCB). Jak je znázorněno v následujícím diagramu, agent Kata poskytuje sadu rozhraní API ttrpc , která umožňují systémovým komponentám mimo TEE vytvářet a spravovat pody Kubernetes založené na důvěrných informacích. Tyto další komponenty (například Kata Shim) nejsou součástí TCB podu. Agent se proto musí chránit před potenciálně chybnými nebo škodlivými voláními rozhraní API.
V důvěrných kontejnerech AKS se rozhraní API agenta Kata implementuje samoobslužná ochrana pomocí zásad zabezpečení (označovaných také jako zásady agenta Kata), které specifikují vlastníci důvěrných podů. Dokument zásad obsahuje pravidla a data odpovídající jednotlivým podům pomocí standardního jazyka zásad rego. Vynucení zásad uvnitř utility virtuálního počítače (UVM) se implementuje pomocí agenta OPA (Open Policy Agent) – odstupňovaný projekt Cloud Native Computing Foundation (CNCF).
Obsah zásad
Zásady zabezpečení popisují všechna volání rozhraní API agenta ttrpc (a parametry těchto volání rozhraní API), která se očekávají při vytváření a správě důvěrného podu. Dokument zásad každého podu je textový soubor pomocí jazyka Rego. Dokument o zásadách obsahuje tři základní části.
Data
Data zásad jsou specifická pro každý pod. Obsahuje například:
- V podu se očekává vytvoření seznamu kontejnerů.
- Seznam rozhraní API blokovaných zásadami ve výchozím nastavení (z důvodů důvěrnosti)
Příklady dat obsažených v dokumentu zásad pro každý kontejner v podu:
- Informace o integritě obrázků
- Příkazy spouštěné v kontejneru
- Svazky úložiště a připojení.
- Kontext zabezpečení spouštění Je například kořenový systém souborů jen pro čtení?
- Je proces povolený získat nová oprávnění?
- Proměnné prostředí.
- Další pole z konfigurace modulu runtime kontejneru Open Container Initiative (OCI).
Pravidla
Pravidla zásad zadaná ve formátu Rego se pro každé volání rozhraní API agenta Kata spouští mimo virtuální počítač nástroje (UVM). Agent poskytuje do OPA všechny vstupy rozhraní API a OPA pomocí pravidel kontroluje, jestli jsou vstupy konzistentní s daty zásad. Pokud pravidla zásad a data nepovolují vstupy rozhraní API, agent odmítne volání rozhraní API vrácením chybové zprávy blokované zásadami. Tady je několik příkladů pravidel:
- Každá vrstva kontejneru je zpřístupněna jako blokové zařízení jen pro čtení pro virtuální počítač nástroje (UVM). Integrita těchto blokových zařízení je chráněná pomocí technologie dm-verity jádra Linuxu. Očekávaná kořenová hodnota hash stromu dm-verity je zahrnutá v datech zásad a ověřená v době běhu pravidly zásad.
- Pravidla odmítnou vytváření kontejnerů, když se zjistí neočekávaný příkazový řádek, připojení úložiště, kontext zabezpečení spouštění nebo proměnná prostředí.
Ve výchozím nastavení jsou pravidla zásad společná pro všechny pody. Nástroj Genpolicy generuje data zásad a je specifický pro každý pod.
Výchozí hodnoty
Při vyhodnocování pravidel rego pomocí dat zásad a vstupů rozhraní API jako parametrů se OPA pokusí najít aspoň jednu sadu pravidel, která vrací true hodnotu na základě vstupních dat. Pokud pravidla nevrací true, OPA vrátí agentovi výchozí hodnotu tohoto rozhraní API. Příklady výchozích hodnot ze zásady:
default CreateContainerRequest := false– znamená, že jakékoli volání rozhraní API CreateContainer je odmítnuto, pokud tato volání explicitně nepovolí sada pravidel zásad.default GuestDetailsRequest := true– znamená, že volání mimo rozhraní TEE do rozhraní GuestDetails API jsou vždy povolená, protože data vrácená tímto rozhraním API nejsou citlivá na důvěrnost úloh zákazníka.
Odeslání zásady do agenta Kata
Všechny virtuální počítače AKS Confidential Container Utility (UVM) se spouštějí pomocí obecných výchozích zásad zahrnutých v kořenovém systému souborů virtuálního počítače NÁSTROJE (UVM). Proto musí být agenta za běhu poskytována zásada, která odpovídá skutečné úloze zákazníka. Text zásady se vloží do souboru manifestu YAML, jak je popsáno výše, a poskytuje se tak agentům včas během inicializace virtuálního počítače nástroje (UVM). Poznámka k zásadám prochází komponentami kubeletu, kontejneru a kata shim systému důvěrné kontejnery AKS. Potom agent, který spolupracuje s OPA, vynucuje zásadu pro všechna volání vlastních rozhraní API.
Tato zásada se poskytuje pomocí komponent, které nejsou součástí TCB, takže zpočátku tato zásada není důvěryhodná. Důvěryhodnost zásad musí být stanovena prostřednictvím vzdáleného ověření identity, jak je popsáno v následující části.
Navázání vztahu důvěryhodnosti v dokumentu zásad
Před vytvořením virtuálního počítače nástroje (UVM) kata vypočítá hodnotu hash SHA256 dokumentu Policy a připojí ji k TEE. Tato akce vytvoří silnou vazbu mezi obsahem zásady a virtuálním počítačem nástroje (UVM). Toto pole TEE není později možné upravit buď softwarem spuštěným uvnitř virtuálního počítače Nástroje (UVM), nebo mimo něj.
Po přijetí zásady agent ověří, že hodnota hash zásady odpovídá neměnným polím TEE. Agent odmítne příchozí zásadu, pokud zjistí neshodu hodnot hash.
Před zpracováním citlivých informací musí vaše úlohy provést kroky vzdáleného ověření identity, aby se prokázaly všem předávajícím stranám, že se úloha spouští pomocí očekávaných verzí TEE, OS, agenta, OPA a verzí kořenového systému souborů. Ověření identity se implementuje v kontejneru spuštěném uvnitř virtuálního počítače nástroje (UVM), který získá podepsané doklady o ověření identity z hardwaru AMD SEV-SNP. Jedním z polí z důkazu ověření identity je pole hodnoty hash zásad TEE popsané výše. Služba Ověření identity proto může ověřit integritu zásady porovnáním hodnoty tohoto pole s očekávanou hodnotou hash zásad podu.
Vynucení zásad
Agent Kata zodpovídá za vynucování zásad. Microsoft přispěl ke komunitě Kata a CoCo kód agenta zodpovědný za kontrolu zásad pro každé volání rozhraní API ttrpc agenta. Před provedením akcí odpovídajících rozhraní API používá agent rozhraní OPA REST API ke kontrole, jestli pravidla zásad a data povolují nebo blokují volání.