Osvědčené postupy pro zabezpečení podů ve službě Azure Kubernetes Service (AKS)

Při vývoji a spouštění aplikací ve službě Azure Kubernetes Service (AKS) je klíčovým aspektem zabezpečení podů. Aplikace by měly být navržené pro princip minimálního počtu požadovaných oprávnění. Zabezpečení privátních dat je pro zákazníky nejdůležitější. Nechcete přihlašovací údaje, jako jsou databázové připojovací řetězec, klíče nebo tajné kódy a certifikáty vystavené vnějšímu světu, kde by útočník mohl tyto tajné kódy využít pro škodlivé účely. Nepřidávejte je do kódu ani je nevkládejte do imagí kontejneru. Tento přístup by vytvořil riziko vystavení a omezil možnost rotace těchto přihlašovacích údajů, protože obrazy kontejnerů bude nutné znovu sestavit.

Tento článek s osvědčenými postupy se zaměřuje na zabezpečení podů v AKS. Naučíte se, jak:

• Použijte kontext zabezpečení podu k omezení přístupu k procesům a službám nebo eskalaci oprávnění.
• Ověřte se u jiných prostředků Azure pomocí identifikátoru úloh Microsoft Entra
• Vyžádání a načtení přihlašovacích údajů z digitálního trezoru, jako je Azure Key Vault

Můžete si také přečíst osvědčené postupy pro zabezpečení clusteru a správu imagí kontejneru.

Zabezpečení přístupu podů k prostředkům

Osvědčené postupy – Pokud chcete spustit jako jiný uživatel nebo skupinu a omezit přístup k procesům a službám podkladového uzlu, definujte nastavení kontextu zabezpečení podů. Přiřaďte nejnižší požadovaný počet oprávnění.

Aby vaše aplikace fungovaly správně, měly by pody běžet jako definovaný uživatel nebo skupina, a ne jako kořen. Pro securityContext pod nebo kontejner můžete definovat nastavení, jako runAsUser nebo fsGroup, k přiřazení příslušných oprávnění. Přiřaďte pouze požadovaná oprávnění uživatele nebo skupiny a nepoužívejte kontext zabezpečení jako prostředek k převzetí dalších oprávnění. Nastavení runAsUser, eskalace oprávnění a dalších možností Linuxu jsou k dispozici pouze na uzlech a podech Linuxu.

Když běžíte jako uživatel bez oprávnění root, kontejnery nemohou svázat s privilegovanými porty pod úrovní 1024. V tomto scénáři je možné službu Kubernetes Services použít k maskování skutečnosti, že aplikace běží na konkrétním portu.

Kontext zabezpečení podů může také definovat další možnosti nebo oprávnění pro přístup k procesům a službám. Můžete nastavit následující běžné definice kontextu zabezpečení:

• allowPrivilegeEscalation definuje, jestli pod může předpokládat kořenová oprávnění. Navrhněte aplikace tak, aby toto nastavení bylo vždy nastaveno na false.
• Možnosti Linuxu umožňují podům přistupovat k podkladovým procesům uzlů. Dbejte opatrnosti při přiřazování těchto možností. Přiřaďte nejnižší počet potřebných oprávnění. Další informace najdete v tématu Možnosti Linuxu.
• Štítky SELinux jsou bezpečnostní modul jádra Linuxu, který umožňuje definovat zásady přístupu pro služby, procesy a přístup k souborovému systému. Znovu přiřaďte nejmenší počet potřebných oprávnění. Další informace najdete v tématu MOŽNOSTI SELinux v Kubernetes.
• hostUsers: False , pod běží pomocí oboru názvů uživatele, funkce jádra Linuxu. To výrazně zlepšuje izolaci hostitele a omezuje boční pohyb v případě úniku kontejneru. Tato vylepšení jsou důležitá bez ohledu na to, jestli je kontejner spuštěný jako kořen, nebo ne. Další informace najdete v tématu obory názvů uživatelů.

Následující příklad manifestu YAML nastavuje nastavení kontextu zabezpečení pro definování:

• Pod běží jako ID uživatele 1000 a jako součást skupiny 2000.
• Nejde eskalovat oprávnění k použití root
• Umožňuje linuxovým schopnostem přistupovat k síťovým rozhraním a hodinám hostitele v reálném čase (hardware).

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Spolupracujte s operátorem clusteru a určete, která nastavení kontextu zabezpečení potřebujete. Navrhněte aplikace tak, aby se minimalizovala další oprávnění a přístup k podu vyžaduje. Existují další funkce zabezpečení, které omezují přístup pomocí AppArmor, seccomp (secure computing) a oborů názvů uživatelů, které můžou implementovat operátoři clusteru.

Další informace najdete v tématu Zabezpečení přístupu ke zdrojům prostřednictvím kontejnerů.

Omezení vystavení přihlašovacích údajů

Pokyny k osvědčeným postupům – Nedefinujte přihlašovací údaje v kódu aplikace. Použijte spravované identity pro prostředky Azure, abyste umožnili vašemu podu žádat o přístup k dalším prostředkům. K ukládání a načítání digitálních klíčů a přihlašovacích údajů by se měl použít také digitální trezor, jako je Azure Key Vault. Identity spravované pody jsou určené jenom pro linuxové pody a image kontejnerů.

Pokud chcete omezit riziko zveřejnění přihlašovacích údajů v kódu aplikace, vyhněte se použití pevných nebo sdílených přihlašovacích údajů. Přihlašovací údaje nebo klíče by neměly být zahrnuty přímo do kódu. Pokud jsou tyto přihlašovací údaje zpřístupněné, je potřeba aplikaci aktualizovat a znovu nasadit. Lepším přístupem je poskytnout podům vlastní identitu a způsob ověřování nebo automatické načtení přihlašovacích údajů z digitálního trezoru.

Použití ID úloh Microsoft Entra

Identita úlohy je identita používaná aplikací běžící na podu, která se může ověřit v jiných službách Azure, které ji podporují, jako je Storage nebo SQL. Integruje se s funkcemi nativními pro Kubernetes pro federaci s externími zprostředkovateli identit. V tomto modelu zabezpečení funguje cluster AKS jako vystavitel tokenu, Microsoft Entra ID používá OpenID Connect ke zjišťování veřejných podpisových klíčů a ověření pravosti tokenu účtu služby před výměnou za token Microsoft Entra. Vaše pracovní zátěž může vyměnit token účtu služeb mapovaný na jeho svazek za token Microsoft Entra pomocí klientské knihovny Azure Identity pomocí sady Azure SDK nebo Knihovny pro ověřování Microsoftu (MSAL).

Další informace o identitách úloh najdete v tématu Konfigurace clusteru AKS pro použití ID úloh Microsoft Entra s vašimi aplikacemi.

Použití Azure Key Vault s ovladačem Secrets Store CSI Driver

Použití ID úloh Microsoft Entra umožňuje ověřování proti podpůrným službám Azure. Pro vlastní služby nebo aplikace bez spravovaných identit pro prostředky Azure se můžete stále ověřovat pomocí přihlašovacích údajů nebo klíčů. Digitální trezor lze použít k ukládání těchto tajných kódů.

Když aplikace potřebují přihlašovací údaje, komunikují s digitálním trezorem, načtou nejnovější obsah tajných kódů a pak se připojí k požadované službě. Azure Key Vault může být tento digitální trezor. Zjednodušený pracovní postup pro načtení přihlašovacích údajů ze služby Azure Key Vault pomocí spravovaných identit podů je znázorněn v následujícím diagramu:

Ve službě Key Vault ukládáte a pravidelně obměňujete tajné kódy, jako jsou přihlašovací údaje, klíče účtu úložiště nebo certifikáty. Službu Azure Key Vault můžete integrovat s clusterem AKS pomocí poskytovatele služby Azure Key Vault pro Secrets Store CSI Driver. Ovladač CSI úložiště tajných kódů umožňuje clusteru AKS nativně načíst obsah tajných kódů ze služby Key Vault a bezpečně je poskytnout pouze požadovanému podu. Spolupracujte s operátorem clusteru a nasaďte ovladač CSI úložiště tajných kódů do pracovních uzlů AKS. Pomocí ID úloh Microsoft Entra můžete požádat o přístup ke službě Key Vault a načíst obsah tajných kódů potřebný prostřednictvím ovladače CSI úložiště tajných kódů.

Další kroky

Tento článek se zaměřuje na zabezpečení podů. Pokud chcete implementovat některé z těchto oblastí, přečtěte si následující články:

• Použijte Microsoft Entra Workload ID pro prostředky Azure s AKS
• Integrace služby Azure Key Vault s AKS