Udostępnij za pośrednictwem

Zagadnienia dotyczące zarządzania tożsamościami i dostępem w usłudze AKS

  • Artykuł

Ten artykuł zawiera zagadnienia dotyczące projektowania i zalecenia dotyczące zarządzania tożsamościami i dostępem podczas korzystania z usługi Azure Kubernetes Service (AKS). Istnieje wiele aspektów zarządzania tożsamościami i dostępem, w tym tożsamości klastra, tożsamości obciążeń i dostępu operatora.

Uwagi dotyczące projektowania

  • Zdecyduj, która tożsamość klastra ma być używana (tożsamość zarządzana lub jednostka usługi).
  • Zdecyduj, jak uwierzytelnić dostęp do klastra: na podstawie certyfikatów klienta lub za pośrednictwem identyfikatora Entra firmy Microsoft.
  • Zdecyduj o klastrze wielodostępności i sposobie konfigurowania kontroli dostępu opartej na rolach (RBAC) na platformie Kubernetes.
    • Wybierz metodę izolacji. Metody obejmują przestrzeń nazw, zasady sieciowe (dozwolone tylko przez usługę Azure CNI), obliczenia (pulę węzłów) i klaster.
    • Określ role RBAC platformy Kubernetes i alokację obliczeniową dla zespołu aplikacji na potrzeby izolacji.
    • Zdecyduj, czy zespoły aplikacji mogą odczytywać inne obciążenia w swoich klastrach, czy w innych klastrach.
  • Określ uprawnienia dla niestandardowych ról RBAC platformy Azure dla strefy docelowej usługi AKS.
    • Zdecyduj, jakie uprawnienia są potrzebne dla roli inżynierii niezawodności lokacji (SRE), aby umożliwić tej roli administrowanie całym klastrem i rozwiązywanie problemów z nim.
    • Zdecyduj, jakie uprawnienia są potrzebne dla metodyki SecOps.
    • Zdecyduj, jakie uprawnienia są wymagane dla właściciela strefy docelowej.
    • Zdecyduj, jakie uprawnienia będą musiały wdrożyć zespoły aplikacji w klastrze.
  • Zdecyduj, czy potrzebujesz tożsamości obciążeń (Tożsamość obciążeń Microsoft Entra). Mogą one być potrzebne w przypadku usług, takich jak integracja usługi Azure Key Vault i usługa Azure Cosmos DB.

Zalecenia dotyczące projektowania

  • Tożsamości klastra.
    • Użyj własnej tożsamości zarządzanej dla klastra usługi AKS.
    • Zdefiniuj niestandardowe role RBAC platformy Azure dla strefy docelowej usługi AKS, aby uprościć zarządzanie wymaganymi uprawnieniami dla tożsamości zarządzanej przez klaster.
  • Dostęp do klastra.
    • Użyj kontroli dostępu opartej na rolach platformy Kubernetes z identyfikatorem Entra firmy Microsoft, aby ograniczyć uprawnienia i zminimalizować uprawnienia administratora. Dzięki temu można chronić dostęp do konfiguracji i wpisów tajnych.
    • Użyj integracji firmy Microsoft Entra zarządzanej przez usługę AKS, aby można było używać identyfikatora Entra firmy Microsoft do uwierzytelniania i dostępu operatora i dewelopera.
  • Zdefiniuj wymagane role RBAC i powiązania ról na platformie Kubernetes.
    • Używanie ról i powiązań ról platformy Kubernetes z grupami firmy Microsoft Entra na potrzeby inżynierii niezawodności lokacji (SRE), SecOps i dostępu deweloperów.
    • Rozważ użycie kontroli dostępu opartej na rolach platformy Azure dla platformy Kubernetes, która umożliwia ujednolicone zarządzanie zasobami platformy Azure, usługą AKS i zasobami kubernetes. Po włączeniu kontroli dostępu opartej na rolach platformy Azure dla platformy Kubernetes nie musisz oddzielnie zarządzać tożsamościami i poświadczeniami użytkowników dla platformy Kubernetes. Podmioty zabezpieczeń firmy Microsoft będą wyłącznie weryfikowane przez kontrolę dostępu opartą na rolach platformy Azure, ale regularni użytkownicy i konta usługi Kubernetes będą wyłącznie weryfikowani przez kontrolę dostępu opartą na rolach platformy Kubernetes.
  • W razie potrzeby przyznaj pełnemu dostępowi SRE just-in-time.
  • Użyj Tożsamość obciążeń Microsoft Entra dla platformy Kubernetes. Podczas implementowania tej federacji deweloperzy mogą używać natywnych kont usługi Kubernetes i federacji do uzyskiwania dostępu do zasobów zarządzanych przez identyfikator Firmy Microsoft Entra, takich jak Azure i Microsoft Graph.