Azure RBAC in Kubernetes-Clustern mit Azure Arc-Unterstützung (Vorschau)

  • 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.

Wichtig

Previewfunktionen von Kubernetes mit Azure Arc-Unterstützung stehen gemäß dem Self-Service-Prinzip und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. Vorschauversionen von Kubernetes mit Azure Arc-Unterstützung werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt.

Aufbau

Diagram showing Azure RBAC architecture.

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