Přehled zabezpečení sítě aplikací Azure Kubernetes (Preview)

Aplikační síť Azure Kubernetes zabezpečuje komunikaci mezi službami v připojených clusterech Azure Kubernetes Service (AKS) prostřednictvím automatického vzájemného ověřování TLS (mTLS) a autorizace na základě identit. Vydává identity úloh a spravuje vystavování, obměna a ověřování certifikátů za účelem povolení šifrované, ověřené a explicitně autorizované komunikace mezi službami bez ruční konfigurace s šifrováním kompatibilním se standardem FIPS při přenosu.

Tento článek obsahuje přehled funkcí zabezpečení ve službě Azure Kubernetes Application Network, včetně mTLS, identit úloh, správy certifikátů a zásad autorizace. Popisuje také omezení a další kroky pro implementaci zabezpečené komunikace v prostředí azure Kubernetes Application Network.

Omezení

• Certifikáty aktuálně vydává certifikační autorita (CA) spravovaná službou Azure Kubernetes Application Network a nejsou zřetězenými s veřejnou certifikační autoritou.

mTLS

Application Network používá mTLS k poskytování šifrované komunikace mezi úlohami založenou na identitě. Každá služba v clusteru připojeném k síti application automaticky obdrží certifikát, který mu umožní prokázat svou identitu a vytvořit důvěryhodná šifrovaná připojení s jinými službami ve stejné aplikační síti. Šifrování při přenosu používá kryptografii kompatibilní s standardem FIPS.

Strategie migrace mTLS

Služba Application Network v současné době umožňuje šifrovaný i nešifrovaný provoz. Tento přístup zajišťuje, aby stávající úlohy fungovaly normálně, zatímco nové nebo aktualizované úlohy automaticky používají mTLS pro zabezpečenou komunikaci. To znamená, že můžete přijmout mTLS pro zabezpečenou komunikaci napříč úlohami bez výpadků. Po dokončení migrace můžete změnit na striktní režim, aby se vynucuje ověřování.

Výhody mTLS v aplikační síti Azure Kubernetes

MTLS v aplikační síti Azure Kubernetes vám pomůže:

• Ochrana přenášených dat: Veškerý provoz mezi službami je možné šifrovat automaticky (kompatibilní se standardem FIPS).
• Ověření identity služby: Každá úloha má jedinečný kořenový a zprostředkující certifikát spravovaný sítí aplikací.
• Zjednodušení operací: Aplikační síť zpracovává vystavování, obměnu a odvolávání certifikátů pro uživatele.

Správa certifikátů

Služba Azure Kubernetes Application Network poskytuje správu certifikátů zajištěnou službou Azure Key Vault, která vydává a udržuje certifikáty používané pro mTLS. Tato služba vytvoří hranici sdílené důvěry napříč všemi clustery AKS připojenými ke stejnému prostředku aplikační sítě.

Application Network automaticky spravuje celý životní cyklus certifikátů pro kořenové a zprostředkující certifikáty, včetně zřizování, obnovení a obměny. Tím zajistíte, že identity úloh zůstanou platné a komunikace zůstane v průběhu času zabezpečená. Certifikáty nemusíte vytvářet, ukládat ani otáčet ručně.

Následující diagram znázorňuje hierarchii certifikátů ve službě Application Network a ukazuje, jak jsou kořenové certifikační autority, zprostředkující certifikační autority a certifikáty úloh strukturované pro navázání důvěryhodnosti mezi připojenými clustery:

Hierarchie certifikátů a životní cyklus

Při vytvoření prostředku Application Network se zřídí kořenová certifikační autorita, která bude sloužit jako důvěryhodný základ pro Application Network. Když se cluster AKS připojí k aplikační síti jako člen, služba Application Network vydá zprostředkující certifikát pro daného člena podepsaného kořenovou certifikační autoritou aplikační sítě. Každý připojený cluster AKS používá zprostředkující certifikát spravovaný službou Application Network k vydávání krátkodobých certifikátů úloh pro úlohy v tomto clusteru.

Všechny certifikáty úloh dědí důvěryhodnost od kořenové certifikační autority aplikační sítě a udržují sjednocenou hranici důvěryhodnosti v rámci prostředku. Obměně kořenových a zprostředkujících certifikátů se pro uživatele zpracovává transparentně, aniž by to způsobilo výpadky nebo přerušení provozu. Tato spravovaná hierarchie zajišťuje konzistentní ověřitelný vztah důvěryhodnosti napříč všemi clustery v aplikační síti a zároveň automaticky zachovává platnost každého certifikátu.

Z kteréhokoli členského clusteru můžete získat kořenový certifikát certifikační autority z konfigurace mapy istio-root-cert v oboru názvů applink-system.

Typy certifikátů a období obměny

Identita a autorizace úloh

S růstem aplikací se služby často potřebují bezpečně komunikovat napříč různými obory názvů a prostředími ve stejném nasazení. Správa certifikátů a zajištění toho, aby každá služba ověřila, s kým mluví, se může rychle stát složitým a náchylným k chybám. Aplikační síť Azure Kubernetes eliminuje tuto režii tím, že automaticky přiřazuje a spravuje identity úloh.

V prostředí připojeném k síti aplikací komunikují úlohy bezpečně uvnitř a napříč obory názvů. Aby každá služba byla důvěryhodná a ověřená, služba Application Network přiřadí každé úloze ověřitelnou identitu , která představuje její obor názvů a účet služby.

Každá úloha aplikační sítě automaticky obdrží jedinečnou identitu ve formátu SPIFFE , která zahrnuje jeho obor názvů a účet služby. Identita je naformátovaná následujícím způsobem:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Tato identita je vložená do certifikátu úlohy a slouží k prokázání identity služby při komunikaci s jinými úlohami. Aplikační síť Azure Kubernetes používá tento model identit založený na technologii SPIFFE se zásadami autorizace Istio, abyste mohli definovat jasná a konzistentní pravidla, pro které služby smí komunikovat.

Definování zásad přístupu

Istio AuthorizationPolicies můžete použít k řízení toho, které pracovní zátěže mají povoleno komunikovat ve vašem prostředí. Tyto zásady umožňují definovat přístup na základě ověřených identit úloh místo síťových umístění nebo IP adres. Tento přístup vám pomůže vynutit konzistentní řízení přístupu i při škálování služeb a přesouvání mezi uzly. Můžete například povolit volání služby pouze konkrétními bránami nebo pracovními zátěžemi z důvěryhodných oborů názvů tím, že odkazujete na jejich identity SPIFFE v seznamu principálů zásad, jak ukazuje následující příklad:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Pokyny k návrhu zásad

Při navrhování zásad autorizace mějte na paměti následující osvědčené postupy:

• Vždy zadejte obor názvů i účet služby, aby se zabránilo neúmyslnému přístupu mezi obory názvů.
• Pomocí principálů definujte explicitní identity úloh pro jemně odstupňovaný přístup.
• Pokud je to vhodné, použijte obory názvů k definování širších hranic důvěryhodnosti.
• Vyhněte se pravidlům, která odpovídají pouze názvům účtů služeb bez uvedení oborů názvů, protože to může udělit přístup napříč clustery nebo prostředími.
• Kombinací AuthorizationPolicies Kubernetes NetworkPolicies vynucujte izolaci založenou na identitě i na síti.

Kombinací spravovaných identit pomocí Azure Kubernetes Application Network, certifikátů a řízení politik můžete implementovat komunikaci služeb s nejnižšími oprávněními založenou na identitě, zajistit ověřený, šifrovaný a explicitně autorizovaný provoz mezi úlohami napříč clustery.

Související obsah

Další informace o aplikační síti Azure Kubernetes najdete v následujících článcích:

• Architektura aplikační sítě Azure Kubernetes
• Přehled pozorovatelnosti aplikační sítě Azure Kubernetes