Share via

Kontrola dostępu oparta na rolach platformy Azure w klastrach Kubernetes z obsługą usługi Azure Arc

  • Artykuł

Typy obiektów Kubernetes ClusterRoleBinding i RoleBinding pomagają w natywnym zdefiniowaniu autoryzacji na platformie Kubernetes. Za pomocą kontroli dostępu opartej na rolach (RBAC) platformy Azure można użyć identyfikatora i przypisań ról firmy Microsoft na platformie Azure, aby kontrolować kontrole autoryzacji w klastrze. Dzięki temu można korzystać z przypisań ról platformy Azure, takich jak dzienniki aktywności pokazujące wszystkie zmiany kontroli dostępu opartej na rolach platformy Azure w zasobie platformy Azure, które mają być używane z klastrem Kubernetes z obsługą usługi Azure Arc.

Architektura

Diagram przedstawiający architekturę RBAC platformy Azure.

Aby skierować wszystkie kontrole dostępu autoryzacji do usługi autoryzacji na platformie Azure, serwer elementu webhook (guard) jest wdrażany w klastrze.

Klaster apiserver jest skonfigurowany do używania uwierzytelniania tokenu elementu webhook i autoryzacji elementu webhook w taki sposób, aby TokenAccessReview żądania i SubjectAccessReview żądania zostały kierowane do serwera elementu webhook guard. Żądania TokenAccessReview i SubjectAccessReview są wyzwalane przez żądania dotyczące zasobów platformy Kubernetes wysyłanych do usługi apiserver.

Następnie funkcja Guard wykonuje checkAccess wywołanie usługi autoryzacji na platformie Azure, aby sprawdzić, czy żądana jednostka Microsoft Entra ma dostęp do zasobu problemu.

Jeśli ta jednostka ma rolę, która zezwala na ten dostęp, allowed odpowiedź jest wysyłana z usługi autoryzacji do ochrony. Funkcja Guard wysyła allowed z kolei odpowiedź na apiserverobiekt , umożliwiając jednostce wywołującej dostęp do żądanego zasobu Kubernetes.

Jeśli jednostka nie ma roli, która zezwala na ten dostęp, denied odpowiedź jest wysyłana z usługi autoryzacji do ochrony. Funkcja Guard wysyła denied odpowiedź na apiserverobiekt , dając jednostce wywołującej błąd 403 zabronionego zasobu.

Następne kroki