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

  • Článek

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 pro vystavení a omezil možnost obměně těchto přihlašovacích údajů, protože image kontejnerů bude potřeba znovu sestavit.

Tento článek s osvědčenými postupy se zaměřuje na zabezpečení podů v AKS. Získáte informace pro:

  • Omezení přístupu k procesům a službám nebo eskalaci oprávnění pomocí kontextu zabezpečení podu
  • Ověřování s využitím jiných prostředků Azure pomocí ID ú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. U securityContext podu nebo kontejneru můžete definovat nastavení, jako je runAsUser nebo fsGroup , abyste mohli předpokládat 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 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 kořenového adresáře, kontejnery nemůžou svázat s privilegovanými porty v rámci verze 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ů. Při přiřazování těchto možností se starají. Přiřaďte nejnižší počet potřebných oprávnění. Další informace najdete v tématu Možnosti Linuxu.
  • Popisky SELinux jsou modul zabezpečení jádra Linuxu, který umožňuje definovat zásady přístupu pro služby, procesy a přístup k systému souborů. 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.

Následující příklad manifestu YAML nastaví nastavení kontextu zabezpečení, které definuje:

  • Pod běží jako ID uživatele 1000 a část ID 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 zjistěte, jaká nastavení kontextu zabezpečení potřebujete. Zkuste navrhnout aplikace, abyste minimalizovali další oprávnění a přistupovali k požadovanému podu. Existují další funkce zabezpečení, které omezují přístup pomocí AppArmor a seccomp (secure computing), které můžou implementovat operátoři clusteru. Další informace najdete v tématu Zabezpečení přístupu ke kontejnerům k prostředkům.

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žití spravovaných identit pro prostředky Azure k tomu, aby pod požadoval přístup k jiný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, Id Microsoft Entra používá openID Připojení ke zjišťování veřejných podpisových klíčů a ověření pravosti tokenu účtu služby před výměnou tokenu microsoft Entra. Vaše úloha může vyměnit token účtu služby promítaný na jeho svazek pro token Microsoft Entra pomocí klientské knihovny azure Identity pomocí sady Azure SDK nebo knihovny Microsoft Authentication Library (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í služby Azure Key Vault s ovladačem CSI úložiště tajných kódů

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:

Simplified workflow for retrieving a credential from Key Vault using a pod managed identity

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 ovladač CSI úložiště tajných kódů. 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: