Osvědčené postupy pro zabezpečení podů v Azure Kubernetes Service (AKS)

Při vývoji a spouštění aplikací v Azure Kubernetes Service (AKS) je klíčovým aspektem zabezpečení podů. Vaše aplikace by měly být navržené pro princip nejmenšího počtu požadovaných oprávnění. Zabezpečení privátních dat je pro zákazníky nejvyšší. Nechcete přihlašovací údaje, jako jsou databázové připojovací řetězce, 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 ke škodlivým účelům. Nevkládávejte je do kódu ani je nevkládávejte do imagí kontejneru. Tento přístup by vytvořil riziko ohrožení a omezil možnost obměně těchto přihlašovacích údajů, protože image kontejnerů bude potřeba znovu vytvořit.

Tento článek o osvědčených postupech se zaměřuje na zabezpečení podů v AKS. Získáte informace o těchto tématech:

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

Zabezpečený přístup 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 základního uzlu, definujte nastavení kontextu zabezpečení podu. Přiřaďte nejmenší požadovaný počet oprávnění.

Aby vaše aplikace správně běží, měly by pody běžet jako definovaný uživatel nebo skupina, a ne jako uživatel root. Pro pod nebo kontejner umožňuje definovat nastavení, jako securityContext je třeba runAsUser nebo fsGroup, a převzít příslušná oprávnění. Přiřaďte pouze požadovaná oprávnění uživatele nebo skupiny a nepoužívejte kontext zabezpečení jako způsob, jak převzít další oprávnění. Nastavení runAsUser, zvýšení úrovně oprávnění a další možnosti Linuxu jsou k dispozici pouze na uzlech a podech Linuxu.

Když spustíte nástroj jako uživatel bez kořenového účtu, kontejnery nemohou vytvořit vazbu na privilegované porty pod 1024. V tomto scénáři je možné pomocí Služby Kubernetes zakrýt skutečnost, že aplikace běží na konkrétním portu.

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

• allowPrivilegeEscalation definuje, jestli pod může předpokládat kořenová oprávnění. Navrhovat aplikace tak, aby toto nastavení bylo vždy nastaveno na hodnotu false.
• Možnosti Linuxu umožňují podu přistupovat k procesům základního uzlu. Při přiřazování těchto funkcí postupujte opatrně. Přiřaďte nejmenší potřebný počet oprávnění. Další informace najdete v tématu Možnosti Linuxu.
• Popisky SELinux je modul zabezpečení jádra Linuxu, který umožňuje definovat zásady přístupu ke službám, procesům a přístupu k systému souborů. Opět přiřaďte nejmenší potřebný počet oprávnění. Další informace najdete v tématu Možnosti SELinux v Kubernetes.

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

• Pod běží jako ID uživatele 1000 a část ID skupiny 2000.
• Nelze eskalovat oprávnění k použití root
• Umožňuje funkcím Linuxu přístup 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, jaká nastavení kontextu zabezpečení potřebujete. Pokuste se navrhnout aplikace, abyste minimalizovali další oprávnění a přístup k podu vyžaduje. Existují další funkce zabezpečení, které omezují přístup pomocí AppArmor a seccomp (zabezpečené výpočetní prostředí), které mohou implementovat operátoři clusteru. Další informace najdete v tématu Zabezpečení přístupu ke kontejneru k prostředkům.

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

Osvědčené postupy – Nedefinujte přihlašovací údaje v kódu aplikace. Pomocí spravovaných identit pro prostředky Azure můžete podu požádat o přístup k jiným prostředkům. Digitální trezor, například Azure Key Vault, by se měl používat také k ukládání a načítání digitálních klíčů a přihlašovacích údajů. Spravované identity podů jsou určené jenom pro použití s pody Linuxu a imagemi kontejnerů.

Pokud chcete omezit riziko, že se přihlašovací údaje v kódu aplikace vystaví, 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 přímo součástí vašeho kódu. Pokud se tyto přihlašovací údaje vystaví, je potřeba aplikaci aktualizovat a znovu nasadit. Lepším přístupem je poskytnout podům vlastní identitu a způsob, jak se ověřit, nebo automaticky načíst přihlašovací údaje z digitálního trezoru.

Použití upstreamových projektů Azure Container Compute

Následující přidružené projekty AKS open source umožňují automaticky ověřovat pody nebo žádat o přihlašovací údaje a klíče z digitálního trezoru. Tyto projekty udržuje upstreamový tým Azure Container Compute a jsou součástí širšího seznamu projektů, které jsou k dispozici pro použití.

• Azure Active Directory Identita podu
• Azure Key Vault provider pro ovladač CSI úložiště tajných kódů

Použití spravovaných identit podů

Spravovaná identita pro prostředky Azure umožňuje, aby se pod ověřil vůči službám Azure, které ho podporují, například Storage nebo SQL. Podu se přiřadí identita Azure, která mu umožní ověření Azure Active Directory a přijetí digitálního tokenu. Tento digitální token je možné předložit dalším službám Azure, které zkontrolují, jestli má pod oprávnění pro přístup ke službě a provádí požadované akce. Tento přístup znamená, že například pro databázové připojovací řetězce nejsou potřeba žádné tajné kódy. Zjednodušený pracovní postup pro spravovanou identitu podu je znázorněn v následujícím diagramu:

Při použití spravované identity nemusí kód aplikace zahrnovat přihlašovací údaje pro přístup ke službě, jako je Azure Storage. Každý pod se ověřuje s vlastní identitou, takže můžete auditovat a zkontrolovat přístup. Pokud se vaše aplikace připojuje k jiným službám Azure, použijte spravované identity k omezení opakovaného použití přihlašovacích údajů a rizika ohrožení.

Další informace o identitách podů najdete v tématu Konfigurace clusteru AKS pro používání spravovaných identit podů a s vašimi aplikacemi.

Použití Azure Key Vault s ovladačem CSI úložiště tajných kódů

Použití projektu identity podu umožňuje ověřování proti podpoře služeb Azure. U vlastních služeb nebo aplikací bez spravovaných identit pro prostředky Azure můžete stále ověřovat pomocí přihlašovacích údajů nebo klíčů. K uložení tohoto tajného obsahu je možné použít digitální trezor.

Když aplikace potřebují přihlašovací údaje, komunikují s digitálním trezorem, načítají nejnovější obsah tajných klíčů a pak se připojují 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ů z Azure Key Vault pomocí spravovaných identit podů je znázorněn v následujícím diagramu:

V Key Vault můžete ukládat a pravidelně obměnovat tajné kódy, jako jsou přihlašovací údaje, klíče účtu úložiště nebo certifikáty. Můžete integrovat Azure Key Vault s clusterem AKS pomocí poskytovatele Azure Key Vault pro ovladač CSI úložištětajných kódů. Ovladač CSI úložiště tajných kódů umožňuje clusteru AKS nativně načítat obsah tajných kódů z Key Vault a bezpečně je poskytovat pouze žádajícímu podu. Spolupracujte s operátorem clusteru a nasaďte ovladač CSI úložiště tajných kódů do pracovních uzlů AKS. Spravovanou identitu podu můžete použít k vyžádání přístupu k Key Vault a načtení tajného obsahu potřebného 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í, podívejte se na následující články:

• Použití spravovaných identit pro prostředky Azure s AKS
• Integrace Azure Key Vault s AKS