Verwenden von 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. Wenn Sie dieses Feature verwenden, können Sie unter Verwendung von Microsoft Entra ID und Rollenzuweisungen in Azure die Autorisierungsüberprüfungen für das Cluster steuern. Mit Azure-Rollenzuweisungen können Sie präzise steuern, welche Benutzer Kubernetes-Objekte wie Bereitstellung, Pod und Dienst lesen, schreiben und löschen können.

Eine konzeptionelle Übersicht zu dieser Funktion finden Sie unter Azure RBAC für Kubernetes mit Azure Arc-Unterstützung.

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.

Voraussetzungen

  • Installieren Sie die Azure-Befehlszeilenschnittstelle, oder upgraden Sie sie auf die neueste Version.

  • Installieren Sie die neueste Version der Azure CLI-Erweiterung connectedk8s:

    az extension add --name connectedk8s

    Wenn die Erweiterung connectedk8s bereits installiert ist, kann sie mit dem folgenden Befehl auf die neueste Version aktualisiert werden:

    az extension update --name connectedk8s

  • Herstellen einer Verbindung mit einem vorhandenen Kubernetes-Cluster mit Azure Arc-Unterstützung:

Hinweis

Dieses Feature kann nicht für Red Hat OpenShift oder verwaltete Kubernetes-Angebote von Cloudanbietern wie Elastic Kubernetes-Dienst oder Google Kubernetes-Engine eingerichtet werden, bei denen der Benutzer keinen Zugriff auf den API-Server des Clusters hat. Für Azure Kubernetes Service-Cluster (AKS) ist dieses Feature nativ verfügbar und erfordert nicht, dass der AKS-Cluster mit Azure Arc verbunden ist.

Einrichten von Microsoft Entra-Anwendungen

Das Erstellen einer Serveranwendung

  1. Erstellen Sie eine neue Microsoft Entra-Anwendung und rufen Sie ihren appId-Wert ab. Dieser Wert wird in späteren Schritten als serverApplicationId verwendet.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. Um der Serveranwendung API-Berechtigungen vom Typ „Anmelden und Benutzerprofil lesen“ zu erteilen, kopieren Sie diesen JSON-Code, und speichern Sie ihn in einer Datei namens „oauth2-permissions.json“:

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. Aktualisieren Sie die Gruppenmitgliedschaftsansprüche für die Anwendung. Führen Sie im selben Verzeichnis, in dem sich auch die Datei oauth2-permissions.json befindet, die Befehle aus. RBAC für Kubernetes mit Azure Arc-Unterstützung erfordert, dass signInAudience auf AzureADMyOrg festgelegt wird:

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. Das Erstellen eines Dienstprinzipals und dessen Feldwert password abrufen. Dieser Wert wird später als serverApplicationSecret benötigt, wenn Sie diese Funktion auf dem Cluster aktivieren. Dieses Geheimnis ist standardmäßig 1 Jahr lang gültig und muss danach rotiert werden. Verwenden Sie az ad sp credential reset, um eine benutzerdefinierte Ablaufdauer festzulegen:

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. Erteilen Sie der Anwendung mithilfe von az ad app permission die API-Berechtigungen „Anmelden und Benutzerprofil lesen“:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Hinweis

    Dieser Schritt muss von einem Azure-Anwendungsadministrator ausgeführt werden.

    Es wird empfohlen, für jeden Cluster eine andere Serveranwendung zu erstellen, um dieses Feature in der Produktion zu verwenden.

Das Erstellen einer Clientanwendung

  1. Erstellen Sie eine neue Microsoft Entra-Anwendung und rufen Sie ihren appId-Wert ab. Dieser Wert wird in späteren Schritten als clientApplicationId verwendet.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. Erstellen Sie einen Dienstprinzipal für diese Clientanwendung:

    az ad sp create --id "${CLIENT_APP_ID}"

  3. Das Abrufen des Werts oAuthPermissionId für die Serveranwendung:

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. Erteilen Sie der Clientanwendung die erforderlichen Berechtigungen. RBAC für Kubernetes mit Azure Arc-Unterstützung erfordert, dass signInAudience auf AzureADMyOrg festgelegt wird:

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

Erstellen einer Rollenzuweisung für die Serveranwendung

Die Serveranwendung benötigt die Berechtigungen Microsoft.Authorization/*/read, um zu überprüfen, ob der Benutzer, der die Anforderung sendet, für die in der Anforderung enthaltenen Kubernetes-Objekte autorisiert ist.

  1. Das Erstellen einer Datei namens accessCheck.json mit den folgenden Inhalten:

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    Das Ersetzen von <subscription-id> durch die tatsächliche Abonnement-ID.

  2. Das Ausführen des folgenden Befehls, um die neue benutzerdefinierte Rolle zu erstellen:

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. Das Erstellen einer Rollenzuweisung auf der Serveranwendung als assignee, durch die Verwendung der von Ihnen erstellten Rolle:

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

Das Aktivieren von Azure RBAC auf dem Cluster

Aktivieren Sie die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) in Ihrem Kubernetes-Cluster mit Azure Arc-Unterstützung, indem Sie den folgenden Befehl ausführen:

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Hinweis

Stellen Sie vor der Ausführung des obigen Befehls sicher, dass die kubeconfig-Datei auf dem Computer auf den Cluster verweist, für den Sie die Azure RBAC-Funktion aktivieren möchten.

Verwenden Sie --skip-azure-rbac-list mit dem vorherigen Befehl, um eine kommagetrennte Liste mit Benutzernamen, E-Mails und OpenID-Verbindungen zu erhalten, die den Berechtigungsprüfungen unterzogen werden. Verwenden Sie hierzu native Kubernetes ClusterRoleBinding- und RoleBinding-Objekte anstelle von Azure RBAC.

Ein generisches Cluster ohne ausgeführte Synchronisierung in der apiserver-Spezifikation

  1. Stellen Sie über SSH eine Verbindung mit jedem Masterknoten des Clusters her, folgen Sie den nachstehenden Schritten:

    Wenn Ihr kube-apiserver ein statischer Pod ist:

    1. Das azure-arc-guard-manifests-Geheimnis im kube-system-Namespace enthält zwei Dateien: guard-authn-webhook.yaml und guard-authz-webhook.yaml. Kopieren Sie diese Dateien in das Verzeichnis /etc/guard des Knotens.

      sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

    2. Öffnen Sie das apiserver-Manifest im Bearbeitungsmodus:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    3. Fügen Sie unter volumes die folgende Spezifikation hinzu:

      - name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

    4. Fügen Sie unter volumeMounts die folgende Spezifikation hinzu:

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

    Wenn Ihr kube-apiserver kein statischer Pod ist:

    1. Öffnen Sie das apiserver-Manifest im Bearbeitungsmodus:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    2. Fügen Sie unter volumes die folgende Spezifikation hinzu:

      - name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

    3. Fügen Sie unter volumeMounts die folgende Spezifikation hinzu:

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

  2. Fügen Sie die folgenden apiserver-Argumente hinzu:

    - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

    Wenn Sie das Kubernetes-Cluster mit der Version 1.19.0 oder höher verwenden, müssen Sie auch das folgende apiserver-Argument festlegen:

    - --authentication-token-webhook-version=v1

  3. Speichern und schließen Sie den Editor, um den apiserver-Pod zu aktualisieren.

Mit Cluster-API erstellte Cluster

  1. Kopieren Sie das Wächtergeheimnis, das die Authentifizierungs- und Autorisierungs-Webhookkonfigurationsdateien aus dem Workloadcluster enthält, auf Ihren Computer:

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

  2. Ändern Sie das Feld namespace in der Datei azure-arc-guard-manifests.yaml in den Namespace innerhalb des Verwaltungsclusters in dem Sie die benutzerdefinierten Ressourcen zur Erstellung von Workloadclustern hinzufügen.

  3. Wenden Sie dieses Manifest an:

    kubectl apply -f azure-arc-guard-manifests.yaml

  4. Bearbeiten Sie das Objekt KubeadmControlPlane durch Ausführung von kubectl edit kcp <clustername>-control-plane:

    1. Fügen Sie unter files den folgenden Codeausschnitt hinzu:

      - contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

    2. Fügen Sie unter apiServer>extraVolumes den folgenden Codeausschnitt hinzu:

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

    3. Fügen Sie unter apiServer>extraArgs den folgenden Codeausschnitt hinzu:

      authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

    4. Wählen Sie speichern und schließen, um das Objekt KubeadmControlPlane zu aktualisieren. Warten Sie, bis diese Änderungen auf dem Workloadcluster angezeigt werden.

Erstellen von Rollenzuweisungen für Benutzer zum Zugriff auf den Cluster

Die Besitzer*innen der Azure Arc-fähigen Kubernetes-Ressource können entweder integrierte oder benutzerdefinierte Rollen verwenden, um anderen Benutzer*innen den Zugriff auf die Kubernetes-Cluster zu gewähren.

Integrierte Rollen

Rolle Beschreibung
Anzeigeberechtigter für Azure Arc Kubernetes Ermöglicht schreibgeschützten Zugriff, um die meisten Objekte in einem Namespace anzuzeigen. Diese Rolle lässt das Anzeigen von geheimen Schlüsseln nicht zu, da die read-Berechtigung für geheime Schlüssel den Zugriff auf ServiceAccount-Anmeldeinformationen im Namespace ermöglichen würde. Diese Anmeldeinformationen würden wiederum den API-Zugriff über den Wert ServiceAccount (eine Form der Rechteauswertung) ermöglichen.
Schreibberechtigter für Azure Arc Kubernetes Ermöglicht Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace. Diese Rolle lässt das Anzeigen oder Ändern von Rollen oder Rollenbindungen nicht zu. Diese Rolle ermöglicht jedoch den Zugriff auf Geheimnisse und das Ausführen von Pods als beliebigen ServiceAccount-Wert im Namespace, sodass sie verwendet werden kann, um die API-Zugriffsebenen für einen beliebigen ServiceAccount-Wert im Namespace zu erhalten.
Azure Arc Kubernetes-Administrator Mit dieser Rolle wird Administratorzugriff gewährt. Sie soll innerhalb eines Namespace durch RoleBinding vergeben werden. Wenn Sie sie in RoleBinding verwenden, wird der Lese-/Schreibzugriff auf die meisten Ressourcen in einem Namespace gewährt, einschließlich der Möglichkeit zum Erstellen von Rollen und Rollenbindungen innerhalb des Namespace. Diese Rolle lässt keinen Schreibzugriff auf das Ressourcenkontingent oder den Namespace selbst zu.
Azure Arc Kubernetes-Clusteradministrator Es ermöglicht den Administratoren-Zugriff, um beliebige Aktionen für beliebige Ressourcen auszuführen. Wenn Sie sie in ClusterRoleBinding verwenden, wird die vollständige Steuerung über jede Ressource in dem Cluster und in allen Namespaces gewährt. Wenn Sie sie in RoleBinding verwenden, wird die vollständige Steuerung über jede Ressource im Namespace der Rollenbindung, einschließlich des Namespace selbst gewährt.

Sie können Rollenzuweisungen, die auf den Azure Arc-fähigen Kubernetes-Cluster beschränkt sind, im Azure-Portal im Bereich Zugriffssteuerung (IAM) der Clusterressource erstellen. Sie können auch die folgenden Azure CLI-Befehle verwenden:

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

Bei diesen Befehlen kann AZURE-AD-ENTITY-ID ein Benutzername (z. B. testuser@mytenant.onmicrosoft.com) oder sogar der appId-Wert eines Dienstprinzipals sein.

Hier sehen Sie ein weiteres Beispiel für die Erstellung einer Rollenzuweisung, die auf einen bestimmten Namespace innerhalb des Clusters bezogen ist:

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Hinweis

Sie können auf den Cluster bezogene Rollenzuweisungen erstellen, indem Sie entweder das Azure-Portal oder die Azure CLI verwenden. Rollenzuweisungen, die auf Namespaces bezogen sind, können aber nur mithilfe der Azure CLI erstellt werden.

Benutzerdefinierte Rollen

Sie können Ihre eigene Rollendefinition für die Verwendung in den Rollenzuweisungen erstellen.

Das folgende Beispiel zeigt eine Rollendefinition, die zulässt, dass der Benutzer die Bereitstellungen nur lesen kann. Weitere Informationen finden Sie in der vollständigen Liste der Datenaktionen, die zum Erstellen einer Rollendefinition verwendet werden können.

Kopieren Sie das nachstehende JSON-Objekt in eine Datei mit dem Namen custom-role.json. Ersetzen Sie den Platzhalter <subscription-id> durch die tatsächliche Abonnement-ID. Die benutzerdefinierte Rolle verwendet eine der Datenaktionen. Sie ermöglicht Ihnen die Anzeige aller Bereitstellungen in dem Bereich (Cluster oder Namespace), in dem die Rollenzuweisung erstellt wird.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

  1. Das Erstellen Sie die Rollendefinition, indem Sie den folgenden Befehl aus dem Ordner ausführen, in dem Sie die Datei custom-role.json gespeichert haben:

    az role definition create --role-definition @custom-role.json

  2. Das Erstellen einer Rollenzuweisung unter Verwendung dieser benutzerdefinierten Rollendefinition:

    az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Konfigurieren von kubectl mit Benutzeranmeldeinformationen

Es gibt zwei Möglichkeiten, die kubeconfig-Datei abzurufen, die Sie für den Zugriff auf den Cluster benötigen:

  • Verwenden Sie die Funktion für die Clusterverbindung (az connectedk8s proxy) des Kubernetes-Clusters mit Azure Arc-Unterstützung.
  • Der Clusteradministrator gibt die kubeconfig-Datei für jeden anderen Benutzer frei.

Verwenden der Clusterverbindung

Führen Sie den folgenden Befehl aus, um den Proxy-Prozess zu starten:

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

Nachdem der Proxy-Prozess ausgeführt wird, können Sie eine weitere Registerkarte in Ihrer Konsole öffnen, um Anforderungen an den Cluster zu senden.

Verwenden einer freigegebenen kubeconfig-Datei

Die Verwendung einer freigegebenen Kubeconfig erfordert je nach Kubernetes-Version geringfügig unterschiedliche Schritte.

  1. Führen Sie den folgenden Befehl aus, um Anmeldeinformationen für den Benutzer festzulegen:

    kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

  2. Öffnen Sie die kubeconfig-Datei, die Sie vorher erstellt haben. Überprüfen Sie unter contexts, dass der mit dem Cluster verknüpfte Kontext auf die Benutzeranmeldeinformationen verweist, die Sie im vorherigen Schritt erstellt haben. Führen Sie den folgenden Befehl aus, um den aktuellen Kontext auf diese Benutzeranmeldeinformationen festzulegen:

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>

  3. Hinzufügen der config-mode-Einstellung unter user>config:

    name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Hinweis

Das Exec-Plug-In ist eine Kubernetes-Authentifizierungsstrategie, mit der kubectl einen externen Befehl ausführen kann, um Benutzeranmeldeinformationen zu empfangen, die an apiserver gesendet werden sollen. Ab Kubernetes Version 1.26 ist das standardmäßige Azure-Autorisierungs-Plug-In nicht mehr in client-go und kubectl enthalten. Mit späteren Versionen müssen Sie Azure Kubelogin, ein client-goexec-Plug-In, das die Azure-Authentifizierung implementiert, verwenden, um das exec-Plug-In zu verwenden, um Benutzeranmeldeinformationen zu erhalten.

  1. Azure Kubelogin installieren:

    • Folgen Sie für Windows oder Mac den Installationsanweisungen von Azure Kubelogin.

    • Laden Sie für Linux oder Ubuntu die neueste Version von Kubelogin herunter und führen Sie dann die folgenden Befehle aus:

      curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin

  2. Konvertieren Sie den Kubelogin so, dass er den entsprechenden Anmeldemodus verwendet. Für die Gerätecodeanmeldung bei einem Microsoft Entra-Benutzer würden die Befehle z. B. wie folgt aussehen:

    export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig

Versenden von Anforderungen an den Cluster

  1. Führen Sie einen beliebigen kubectl-Befehl aus. Beispiel:

    • kubectl get nodes
    • kubectl get pods

  2. Wenn Sie zur Durchführung der browserbasierten Authentifizierung aufgefordert werden, kopieren Sie die URL (https://microsoft.com/devicelogin) für die Geräteanmeldung, und öffnen Sie diese in Ihrem Webbrowser.

  3. Geben Sie den auf Ihrer Konsole aufgedruckten Code ein. Kopieren Sie den Code und fügen Sie ihn auf Ihrem Endgerät in die Eingabeaufforderung für die Geräteauthentifizierung ein.

  4. Geben Sie den Benutzernamen (testuser@mytenant.onmicrosoft.com) und das zugehörige Kennwort ein.

  5. Falls eine Fehlermeldung, wie die folgende, angezeigt wird, sind Sie nicht berechtigt auf die angeforderte Ressource zuzugreifen:

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

    Ein Administrator muss eine neue Rollenzuweisung erstellen, die diesem Benutzer den Zugriff auf die Ressource gewährt.

Bedingten Zugriff mit Microsoft Entra ID verwenden

Wenn Sie Microsoft Entra ID mit Ihrem Azure Arc-fähigen Kubernetes-Cluster integrieren, können Sie den Zugriff darauf auch mithilfe des bedingten Zugriffs steuern.

Hinweis

Microsoft Entra Conditional Access ist eine Microsoft Entra ID P2-Funktion.

So erstellen Sie eine Beispielrichtlinie für bedingten Zugriff, die mit dem Cluster verwendet werden soll

  1. Suchen Sie ganz oben im Azure-Portal nach Microsoft Entra ID und wählen Sie den Eintrag aus.

  2. Wählen Sie im Menü für Microsoft Entra-ID auf der linken Seite Enterprise-Anwendungenaus.

  3. Wählen Sie auf der linken Seite im Menü „Unternehmensanwendungen“ Bedingter Zugriff aus.

  4. Wählen Sie auf der linken Seite im Menü „Bedingter Zugriff“ Richtlinien>Neue Richtlinie aus.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Geben Sie einen Namen für die Richtlinie, z. B. arc-k8s-Richtlinie, ein.

  6. Wählen Sie Benutzer und Gruppen aus. Wählen Sie unter Einschließen die Option Benutzer und Gruppen auswählenaus. Wählen Sie dann die Benutzer und Gruppen aus, auf die Sie die Richtlinie anwenden möchten. Wählen Sie in diesem Beispiel dieselbe Microsoft Entra-Gruppe aus, die Administratorzugriff auf Ihr Cluster hat.

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. Wählen Sie Cloud-Apps oder -aktionen aus. Wählen Sie unter Einschließen die Option Apps auswählen aus. Suchen Sie dann nach der Serveranwendung, die Sie zuvor erstellt haben, und wählen Sie sie aus.

    Screenshot showing how to select a server application in the Azure portal.

  8. Klicken Sie unter Zugriffssteuerungen auf Gewähren. Wählen Sie Zugriff gewähren>Markieren des Geräts als konform erforderlich aus.

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. Wählen Sie unter Richtlinie aktivieren die Option An>Erstellen aus.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

Ein erneutes Zugreifen auf den Cluster. Das Ausführen des kubectl get nodes-Befehls zum Anzeigen der Knoten im Cluster:

kubectl get nodes

Befolgen Sie die Anweisungen zum erneuten Anmelden. Eine Fehlermeldung zeigt an, dass Sie erfolgreich angemeldet sind. Ihr Administrator fordert aber an, dass das Zugriff anfordernde Gerät von Ihrem Microsoft Entra ID verwaltet werden muss, damit es auf die Ressource zugreifen kann. Führen Sie folgende Schritte aus:

  1. Navigieren Sie im Azure-Portal zu Microsoft Entra ID.

  2. Wählen Sie Unternehmensanwendungen. Wählen Sie dann unter Aktivität die Option Anmeldungen aus.

  3. Ein Eintrag oben zeigt einen Fehler für den Status und den Erfolg für den bedingten Zugriff an. Wählen Sie den Eintrag und dann unter Details die Option Bedingter Zugriff aus. Wie Sie sehen können, ist Ihre Richtlinie für den bedingten Zugriff aufgeführt.

    Screenshot showing a failed sign-in entry in the Azure portal.

Konfigurieren des Just-in-Time-Clusterzugriffs mit Microsoft Entra ID

Eine weitere Option für die Clusterzugriffssteuerung ist die Verwendung von Privileged Identity Management (PIM) für Just-In-Time-Anforderungen.

Hinweis

Microsoft Entra PIM ist eine Microsoft Entra ID P2-Funktion. Weitere Informationen zu Microsoft Entra ID SKUs finden Sie im Preisleitfaden.

Führen Sie die folgenden Schritte aus, um die Just-In-Time-Zugriffsanforderungen für Ihren Cluster zu konfigurieren:

  1. Suchen Sie ganz oben im Azure-Portal nach Microsoft Entra ID und wählen Sie den Eintrag aus.

  2. Notieren Sie die Mandanten-ID. Im nachfolgenden Teil dieser Anleitung bezeichnen wir diese ID als <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. Wählen Sie im Menü für die Microsoft Entra-ID auf der linken Seite unter VerwaltenGruppen>Neue Gruppe aus.

  4. Stellen Sie sicher, dass die Sicherheit als Gruppentyp ausgewählt ist. Die Eingabe eine Gruppennamens, z. B. myJITGroup. Wählen Sie unter Microsoft Entra-Rollen können der Gruppe zugewiesen werden (Vorschau) die Option Ja aus. Wählen Sie abschließend Erstellen.

    Screenshot showing details for the new group in the Azure portal.

  5. Sie werden zur Seite Gruppen zurückgeleitet. Wählen Sie Ihre neu erstellte Gruppe aus, und notieren Sie die Objekt-ID. Im nachfolgenden Teil dieser Anleitung bezeichnen wir diese ID als <object-id>.

    Screenshot showing the object ID for the new group in the Azure portal.

  6. Zurück im Azure-Portal, wählen Sie auf der linken Seite im Menü Aktivität die Option Privilegierter Zugriff (Vorschau) aus. Wählen Sie dann Privilegierten Zugriff aktivieren aus.

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. Wählen Sie Zuweisungen hinzufügen aus, um mit der Zugriffsgewährung zu beginnen.

    Screenshot showing how to add active assignments in the Azure portal.

  8. Wählen Sie eine Rolle für das Mitglied und anschließend die Benutzer und Gruppen aus, denen Sie Clusterzugriff gewähren möchten. Ein Gruppenadministrator kann diese Zuweisungen jederzeit ändern. Wenn Sie so weit sind, wählen Sie Weiter aus.

    Screenshot showing how to add assignments in the Azure portal.

  9. Wählen Sie einen Zuweisungstyp von Aktiv und die gewünschte Dauer aus, und geben Sie eine Begründung an. Wenn Sie so weit sind, wählen Sie Zuweisen aus. Weitere Informationen zu Zuweisungstypen finden Sie unter Zuweisen eines Besitzers oder Mitglieds einer Gruppe.

    Screenshot showing assignment properties in the Azure portal.

Überprüfen Sie sich nach dem Einrichtung der Zuweisungen, dass der Just-In-Time-Zugriff funktioniert, indem Sie auf den Cluster zugreifen. Verwenden Sie dafür z. B. den kubectl get nodes-Befehl zum Anzeigen der Knoten im Cluster:

kubectl get nodes

Beachten Sie die Authentifizierungsanforderung, und führen Sie die Authentifizierungsschritte aus. Wenn der Authentifizierungsvorgang erfolgreich war, sollte eine Ausgabe wie diese angezeigt werden:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

Aktualisieren des Geheimnisses der Serveranwendung

Wenn das Geheimnis des Dienstprinzipals der Serveranwendung abgelaufen ist, müssen Sie es rotieren.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Aktualisieren Sie das Geheimnis im Cluster. Fügen Sie alle optionalen Parameter hinzu, die Sie konfiguriert haben, als dieser Befehl ursprünglich ausgeführt wurde.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Nächste Schritte