Verwenden von Privileged Identity Management (PIM) zum Steuern des Zugriffs auf Ihre Azure Kubernetes Service (AKS)-Cluster

Artikel
10/15/2024

Wenn Sie Berechtigungen für unterschiedliche Teams einrichten, sollten Sie bei Bedarf Standardberechtigungen für bestimmte Teams festlegen und dann bestimmten Benutzern privilegierten Zugriff gewähren. Mithilfe von Azure Kubernetes Service (AKS) mit Microsoft Entra ID können Sie Privileged Identity Management (PIM) für Just-in-Time-Anforderungen (JIT) einrichten.

In diesem Artikel werden folgende Vorgehensweisen behandelt:

Legen Sie Standardrollen fest, z. B. Gruppen, um auf AKS-Cluster basierend auf Microsoft Entra-Gruppenmitgliedschaften zuzugreifen oder Vorgänge auszuführen.
Konfigurieren Sie grundlegende Rollen für den Zugriff auf AKS-Cluster.
Aktivierten Sie Rollen selbst, um Just-in-Time-Zugang zu AKS-Clustern zu erhalten.
Legen Sie genehmigende Personen fest, um Genehmigungsanforderungen für Just-in-Time-Zugriff zu genehmigen oder zu verweigern.

Hinweis

Microsoft Entra Privileged Identity Management (PIM) verfügt über Microsoft Entra ID P2- oder Microsoft Entra ID Governance-Funktionen, die eine Premium P2-SKU erfordern. Weitere Informationen finden Sie unter Microsoft Entra ID Governance–Lizenzierungsgrundlagen und Preisleitfaden.

Voraussetzungen

In diesem Artikel wird davon ausgegangen, dass Sie über ein vorhandenes AKS-Cluster mit Microsoft Entra ID-Integration verfügen. Wenn Sie keins haben, lesen Sie Erstellen eines AKS-Clusters mit Microsoft Entra ID-Integration.

Erstellen von Demogruppen in Microsoft Entra ID

In diesem Abschnitt erstellen wir drei Gruppen in Microsoft Entra ID:

Standard: Diese Gruppe hat schreibgeschützten Zugriff (Azure Kubernetes Service RBAC Reader) auf Ressourcen im AKS-Cluster.
Administrator: Diese Gruppe hat Administratorzugriff (Azure Kubernetes Service RBAC Admin) auf Ressourcen im AKS-Cluster.
Genehmigende Person: Diese Gruppe verfügt über Berechtigungen zum Genehmigen oder Verweigern von Anforderungen für Just-In-Time-Zugriff auf das AKS-Cluster.

Sie können einfach die Standard- und Administratorgruppen verwenden, anstatt eine separate genehmigende Gruppe zu erstellen. Wenn Sie jedoch Genehmigungsberechtigungen in die Administratorgruppe einschließen, kann das Mitglied, das Just-In-Time-Zugriff erhält, seine eigenen Anforderungen und die Anforderungen anderer genehmigen. Es wird nicht empfohlen, diese Konfiguration in einer Produktionsumgebung zu verwenden, sie ist aber für Testzwecke nützlich.

Standardgruppe erstellen

Rufen Sie die Ressourcen-ID des AKS-Clusters mithilfe des az aks show-Befehls ab.

AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

Rufen Sie die Ressourcengruppen-ID des AKS-Clusters mithilfe des az group show-Befehls ab.

RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)

Erstellen Sie die Standardgruppe mithilfe des az ad group create-Befehls.

DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

Erstellen Sie mithilfe des Befehls az role assignment create eine Azure-Rollenzuweisung für die Standardgruppe.

Es gibt drei Rollen, die Sie der Standardgruppe je nach Ihren spezifischen Anforderungen zuweisen können:
- Azure Kubernetes Service RBAC Reader: Zugewiesen im Bereich des AKS-Clusters und bietet einfachen schreibgeschützten Zugriff auf die meisten Ressourcen im Cluster.
- Reader: Zugewiesen im Bereich der Ressourcengruppe und bietet schreibgeschützten Zugriff auf Ressourcen in der Ressourcengruppe.
- Azure Kubernetes Service Cluster User Role: Zugewiesen im Bereich des AKS-Clusters und gewährt Zugriff auf den Kubeconfig-Kontext für das AKS-Cluster.
```
# Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID
```

Erstellen einer Administratorgruppe

Erstellen Sie die Administratorgruppe mithilfe des az ad group create-Befehls.

ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

Weisen Sie der Administratorgruppe die Azure Kubernetes Service RBAC Admin-Rolle mithilfe des az role assignment create-Befehls zu.

az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID

Hinweis

Wenn Sie Benutzern in der Administratorgruppe das Ändern von Knotenpooleinstellungen wie der manuellen Skalierung ermöglichen möchten, müssen Sie mithilfe des folgenden Befehls eine Contributor-Rollenzuweisung im Clusterknotenpool erstellen:

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

Beachten Sie, dass dies nur die Berechtigung zum Skalieren nach oben oder unten von der AKS-Ressource erteilt. Wenn Sie die Skalierung von der VM-Skalierungssatzressource zulassen möchten, müssen Sie eine Zuordnung auf der Ebene des Skalierungssatzes für virtuelle Computer erstellen.

Gruppe genehmigender Personen erstellen

Erstellen Sie die genehmigende Gruppe mit dem az ad group create-Befehl.

APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

Erstellen von Demobenutzer*innen in Microsoft Entra ID

In diesem Abschnitt erstellen wir zwei Benutzer in Microsoft Entra ID: Einen normalen Benutzer mit nur der Standardrolle und einen privilegierten Benutzer, der Just-in-Time-Anforderungen vom normalen Benutzer genehmigen oder verweigern kann.

Erstellen Sie den normalen Benutzer mithilfe des az ad user create-Befehls.

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

Fügen Sie den normalen Benutzer mithilfe des az ad group member add-Befehls zur Standardgruppe hinzu.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Erstellen Sie den privilegierten Benutzer mithilfe des az ad user create-Befehls.

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

Fügen Sie den privilegierten Benutzer mithilfe des az ad group member add-Befehls zur genehmigenden Gruppe hinzu.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Privileged Identity Management (PIM) für die Administratorgruppe aktivieren

Wählen Sie auf derStartseite im Azure-Portal Microsoft Entra ID aus.
Wählen Sie im Dienstmenü unter Verwalten Gruppen aus, und wählen Sie dann die Gruppe Administrator aus.
Wählen Sie im Dienstmenü unter Aktivität Privileged Identity Management aus, und wählen Sie dann PIM für diese Gruppe aktivieren aus.

Festlegen einer genehmigenden Person für die Administratorgruppe

Suchen Sie auf der Startseite des Azure-Portals nach Privileged Identity Management und wählen Sie es aus.
Wählen Sie im Dienstmenü unter Verwalten Gruppen aus, und wählen Sie dann die Gruppe Administrator aus.
Wählen Sie im Dienstmenü unter Verwalten Aufgaben>Aufgaben hinzufügen aus.
Wählen Sie auf der Registerkarte Mitgliedschaft der Seite Aufgaben hinzufügen Mitglied als ausgewählte Rolle und Standard als ausgewähltes Mitglied aus, und wählen Sie dann Weiter aus.
Wählen Sie auf der Registerkarte Einstellungen Berechtigt als Zuordnungstyp aus, und wählen Sie dann Zuweisen aus.
Wählen Sie im Dienstmenü unter Verwalten Einstellungen>Mitglied>Bearbeiten aus.
Aktivieren Sie auf der Seite Rolle bearbeiten – Mitglied das Kontrollkästchen Genehmigung zum Aktivieren erforderlich aus und fügen Sie die genehmigende Gruppe als ausgewählte genehmigende Person hinzu.

Hinweis

Wenn Sie das Kontrollkästchen Genehmigung zum Aktivieren anfordern, können die Benutzer in der Standardgruppe die Rolle selbst aktivieren, um Just-In-Time-Zugriff auf das AKS-Cluster ohne Genehmigung zu erhalten. Der Benutzer in der genehmigenden Gruppe muss Mitglied der Gruppe sein. Selbst wenn Sie den Benutzer als Besitzer festlegen, können sie immer noch keine Just-in-Time-Anforderungen überprüfen, da der Gruppenbesitzer nur über Administratorrechte für die Gruppe verfügt, nicht über die Rollenzuweisung. Sie können den Benutzer ohne Konflikte als Mitglied und Besitzer derselben Gruppe festlegen.
Nehmen Sie alle anderen erforderlichen Änderungen vor und wählen Sie dann Aktualisieren aus.

Weitere Informationen zur PIM-Konfiguration finden Sie unter Konfigurieren von PIM für Gruppen.

Interagieren mit Clusterressourcen mithilfe der Standardrolle

Jetzt können wir versuchen, mithilfe des normalen Benutzers, der Mitglied der Standardgruppe ist, auf das AKS-Cluster zuzugreifen.

Melden Sie sich beim Azure-Portal als normaler Benutzer mit dem az login-Befehl an.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Rufen Sie die Benutzeranmeldeinformationen für den Zugriff auf den Cluster mit dem Befehl az aks get-credentials ab.
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Versuchen Sie, mithilfe des kubectl get-Befehls auf die Cluster-Pods zuzugreifen.

kubectl get pods --namespace kube-system

Die Ausgabe sollte ähnlich wie die folgende Beispielausgabe aussehen, welche die Pods im kube-system-Namespace anzeigt:

NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

Versuchen Sie, mithilfe des kubectl get-Befehls auf die geheimen Clusterschlüssel zuzugreifen.
```
kubectl get secrets --namespace kube-system
```
Die Ausgabe sollte ähnlich wie die folgende Beispielausgabe aussehen, die eine Fehlermeldung anzeigt, da der Benutzer nicht über die Berechtigung zum Zugriff auf die geheimen Schlüssel verfügt:
```
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.
```
Die Azure Kubernetes Service RBAC Reader-Rolle verfügt nicht über die Berechtigung für den Zugriff auf geheime Schlüssel, sodass dieser Fehler erwartet wird.

Just-in-Time-Zugriff auf das AKS-Cluster anfordern

Dieses Mal können wir Just-In-Time-Zugriff als vorübergehendes Azure Kubernetes Service RBAC Admin anfordern, indem wir die Schritte unter Aktivieren Ihrer Gruppenmitgliedschaft oder des Besitzes in Privileged Identity Management ausführen. Informationen zum Genehmigen oder Ablehnen von Anforderungen als genehmigende Person finden Sie unter Genehmigen von Aktivierungsanforderungen für Gruppenmitglieder und Besitzer.

Interagieren mit Clusterressourcen mithilfe der Administratorrolle

Nachdem Sie die Azure Kubernetes Service RBAC Admin-Rolle vorübergehend hinzugefügt haben, können Sie auf die Clusterressourcen zugreifen, die Administratorberechtigungen erfordern.

Entfernen Sie vorhandene gespeicherte Token mithilfe des folgenden kubelogin-Befehls:
```
kubelogin remove-tokens
```
Hinweis

Wenn aufgrund fehlender Berechtigungen ein Fehler auftritt, melden Sie sich an, um die Berechtigungen mithilfe des az login-Befehls zu aktualisieren.
Versuchen Sie erneut, mithilfe des kubectl get secrets-Befehls auf die geheimen Clusterschlüssel zuzugreifen.
```
kubectl get secrets --namespace kube-system
```
Die Ausgabe sollte ähnlich wie die folgende Beispielausgabe aussehen, welche die geheimen Schlüssel im kube-system-Namespace anzeigt:
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
Der Benutzer kann jetzt auf die geheimen Schlüssel zugreifen, da er über die Azure Kubernetes Service RBAC Admin-Rolle verfügt.

Überlegungen zur Tokenlebensdauer

Aufgrund des Designs der Tokenlebensdauer, wenn Sie Benutzern, die CLI-Tools wie kubectl oder kubelogin verwenden, Rollen gewähren, kann die Aktivierungsdauer technisch nicht kleiner als 60 Minuten sein. Auch wenn die Dauer auf weniger als 60 Minuten festgelegt ist, bleibt die tatsächliche effektive Dauer zwischen 60 und 75 Minuten.

Wenn kubelogin versucht Token von der Microsoft Identity Platform abzurufen werden access_token und refresh_token zur weiteren Verwendung zurückgegeben werden. Die access_token stellt Anforderungen an die API und die refresh_token wird verwendet, um ein neues access_token abzurufen, wenn das aktuelle abläuft. Die access_token kann nicht widerrufen werden, nachdem sie generiert wurde, aber die refresh_token kann widerrufen werden. Wenn der refresh_token-Vorgang widerrufen wird, muss sich der Benutzer erneut authentifizieren, um ein neues refresh_token zu erhalten. Um den refresh_token manuell zu widerrufen, können Sie Revoke-AzureADUserAllRefreshToken verwenden.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln:

Freigeben über