Azure RBAC auf Azure Arc-fähigen Kubernetes-Clustern

  • Artikel

Die Kubernetes-Objekttypen „ClusterRoleBinding“ und „RoleBinding“ bieten Unterstützung bei der nativen Definition der Autorisierung in Kubernetes. Mit Azure RBAC (rollenbasierte Zugriffssteuerung) können Sie unter Verwendung von Microsoft Entra ID und Rollenzuweisungen in Azure Autorisierungsüberprüfungen für den Cluster steuern. Damit können alle Vorteile von Azure-Rollenzuweisungen wie Aktivitätsprotokolle, die alle Azure RBAC-Änderungen an einer Azure-Ressource zeigen, mit Ihrem Kubernetes-Cluster mit Azure Arc-Unterstützung angewandt werden.

Aufbau

Diagramm: Azure RBAC-Architektur

Um alle Autorisierungszugriffsüberprüfungen an den Autorisierungsdienst in Azure weiterzuleiten, wird ein Webhookserver (Wächter) im Cluster bereitgestellt.

Der apiserver des Clusters ist so konfiguriert, dass eine Webhooktokenauthentifizierung und eine Webhookautorisierung verwendet werden, sodass TokenAccessReview- und SubjectAccessReview-Anforderungen an den Wächterwebhookserver weitergeleitet werden. Die TokenAccessReview- und SubjectAccessReview-Anforderungen werden durch Anforderungen an Kubernetes-Ressourcen ausgelöst, die an den apiserver gesendet werden.

Der Wächter richtet dann einen checkAccess-Aufruf an den Autorisierungsdienst in Azure, um festzustellen, ob die anfordernde Microsoft Entra-Entität Zugriff auf die betreffende Ressource hat.

Wenn diese Entität eine Rolle hat, die diesen Zugriff zulässt, wird vom Autorisierungsdienst eine allowed-Antwort an den Wächter gesendet. Der Wächter sendet wiederum eine allowed-Antwort an den apiserver, sodass die aufrufende Entität auf die angeforderte Kubernetes-Ressource zugreifen kann.

Wenn diese Entität keine Rolle hat, die diesen Zugriff zulässt, wird vom Autorisierungsdienst eine denied-Antwort an den Wächter gesendet. Der Wächter sendet eine denied-Antwort an den apiserver und meldet der aufrufenden Entität einen „403 – Unzulässig“-Fehler für die angeforderte Ressource.

Nächste Schritte