Použití privileged Identity Management (PIM) k řízení přístupu ke clusterům Azure Kubernetes Service (AKS)

Článek
09/04/2024

Při nastavování oprávnění pro různé týmy můžete chtít nastavit výchozí oprávnění pro zadané týmy a v případě potřeby udělit privilegovaný přístup konkrétním uživatelům. Použití služby Azure Kubernetes Service (AKS) s Microsoft Entra ID umožňuje nastavit Privileged Identity Management (PIM) pro požadavky PODLE potřeby (JIT).

V tomto článku získáte informace o těchto tématech:

Nastavte výchozí role, například skupiny pro přístup k clusterům AKS nebo provádění operací na základě členství ve skupinách Microsoft Entra.
Nakonfigurujte základní role pro přístup ke clusterům AKS.
Role samoobslužné aktivace pro získání přístupu k clusterům AKS za běhu
Nastavte schvalovatele tak, aby schvalovat nebo odepřely žádosti o schválení pro přístup za běhu.

Poznámka:

Microsoft Entra Privileged Identity Management (PIM) má možnosti zásad správného řízení Microsoft Entra ID P2 nebo Microsoft Entra ID, které vyžadují skladovou položku Premium P2. Další informace najdete v tématu Základy licencování zásad správného řízení a cenových zásad správného řízení Microsoft Entra ID.

Požadavky

Tento článek předpokládá, že máte existující cluster AKS s integrací Microsoft Entra ID. Pokud ho nemáte, přečtěte si téma Vytvoření clusteru AKS s integrací Microsoft Entra ID.

Vytvoření ukázkových skupin v Microsoft Entra ID

V této části vytvoříme tři skupiny v ID Microsoft Entra:

Výchozí nastavení: Tato skupina má přístup jen pro čtení (Azure Kubernetes Service RBAC Reader) k prostředkům v clusteru AKS.
Správce: Tato skupina má přístup správce (Azure Kubernetes Service RBAC Admin) k prostředkům v clusteru AKS.
Schvalovatel: Tato skupina má oprávnění ke schválení nebo zamítnutí žádostí o přístup ke clusteru AKS za běhu.

Místo vytvoření samostatné skupiny schvalovatele můžete použít jenom výchozí skupiny a skupiny pro správu. Pokud ale do skupiny pro správu zahrnete oprávnění ke schválení, může člen, který získá přístup za běhu, schválit vlastní žádosti a žádosti ostatních. Tuto konfiguraci nedoporučujeme používat v produkčním prostředí, ale je užitečná pro účely testování.

Vytvoření výchozí skupiny

Pomocí příkazu získejte ID prostředku clusteru az aks show AKS.

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

Pomocí příkazu získejte ID skupiny prostředků clusteru az group show AKS.

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

Pomocí příkazu vytvořte výchozí skupinu az ad group create .

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

Pomocí příkazu vytvořte přiřazení role Azure pro výchozí skupinu az role assignment create .

Výchozí skupinu můžete přiřadit třemi rolemi v závislosti na konkrétních požadavcích:
- Azure Kubernetes Service RBAC Reader: Přiřazeno v oboru clusteru AKS a poskytuje základní přístup jen pro čtení k většině prostředků v clusteru.
- Reader: Přiřazeno v oboru skupiny prostředků a poskytuje přístup k prostředkům ve skupině prostředků jen pro čtení.
- Azure Kubernetes Service Cluster User Role: Přiřazeno v oboru clusteru AKS a poskytuje přístup k získání kontextu kubeconfig pro cluster AKS.
```
# 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
```

Vytvoření skupiny správců

Pomocí příkazu vytvořte skupinu az ad group create správců.

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

Azure Kubernetes Service RBAC Admin Pomocí příkazu přiřaďte roli skupině az role assignment create správců.

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

Poznámka:

Pokud chcete uživatelům ve skupině správců povolit změnu nastavení fondu uzlů, jako je ruční škálování, musíte ve fondu uzlů clusteru vytvořit Contributor přiřazení role pomocí následujícího příkazu:

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

Mějte na paměti, že to dává oprávnění pouze k horizontálnímu navýšení nebo snížení kapacity z prostředku AKS. Pokud chcete povolit horizontální navýšení nebo snížení kapacity z prostředku škálovací sady virtuálních počítačů, musíte vytvořit přiřazení na úrovni škálovací sady virtuálních počítačů.

Vytvoření skupiny schvalovatele

Pomocí příkazu vytvořte skupinu schvalovatelůaz ad group create.

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

Vytvoření ukázkových uživatelů v Microsoft Entra ID

V této části vytvoříme dva uživatele v Microsoft Entra ID: normální uživatel s pouze výchozí rolí a privilegovaný uživatel, který může schválit nebo odepřít žádosti za běhu od normálního uživatele.

Pomocí příkazu vytvořte normálního az ad user create uživatele.

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)

Pomocí příkazu přidejte normálního uživatele do výchozí skupinyaz ad group member add.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Pomocí příkazu vytvořte privilegovaného uživatele az ad user create .

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

Přidejte privilegovaného uživatele do skupiny schvalovatele pomocí az ad group member add příkazu.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Povolení privileged Identity Management (PIM) pro skupinu správců

Na domovské stránce webu Azure Portal vyberte ID Microsoft Entra.
V nabídce služby v části Spravovat vyberte Skupiny a pak vyberte skupinu správců.
V nabídce služby v části Aktivita vyberte Privileged Identity Management a pak vyberte Povolit PIM pro tuto skupinu.

Nastavení schvalovatele pro skupinu správců

Na domovské stránce webu Azure Portal vyhledejte a vyberte Privileged Identity Management.
V nabídce služby v části Spravovat vyberte Skupiny a pak vyberte skupinu správců.
V nabídce služby v části Spravovat vyberte Přiřazení>Přidat přiřazení.
Na kartě Členství na stránce Přidat přiřazení vyberte jako vybranou roli Člen a jako vybraný člen vyberte výchozí hodnotu a pak vyberte Další.
Na kartě Nastavení vyberte Možnost jako typ přiřazení a pak vyberte Přiřadit.
V nabídce služby v části Spravovat vyberte Upravit člena>nastavení.>
Na stránce Upravit roli – Člen zaškrtněte políčko Vyžadovat schválení k aktivaci a přidejte skupinu schvalovatelů jako vybraného schvalovatele.

Poznámka:

Pokud nezaškrtnete políčko Vyžadovat schválení k aktivaci , můžou uživatelé ve výchozí skupině sami aktivovat roli, aby získali přístup ke clusteru AKS za běhu bez schválení. Uživatel ve skupině schvalovatele musí být členem skupiny. I když nastavíte uživatele jako vlastníka, nebudou moct kontrolovat žádosti za běhu, protože vlastník skupiny má jenom oprávnění správce ke skupině, ne přiřazení role. Uživatele můžete nastavit jako člena a vlastníka stejné skupiny bez konfliktu.
Proveďte všechny další potřebné změny a pak vyberte Aktualizovat.

Další informace o konfiguraci PIM naleznete v tématu Konfigurace PIM pro skupiny.

Interakce s prostředky clusteru pomocí výchozí role

Teď se můžeme pokusit o přístup ke clusteru AKS pomocí normálního uživatele, který je členem výchozí skupiny.

Přihlaste se k webu Azure Portal jako normální uživatel pomocí az login příkazu.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Pomocí příkazu získejte přihlašovací údaje uživatele pro přístup ke clusteru az aks get-credentials .
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Zkuste získat přístup k podům clusteru kubectl get pomocí příkazu.

kubectl get pods --namespace kube-system

Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje pody v kube-system oboru názvů:

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

Zkuste získat přístup k tajným kódům clusteru kubectl get pomocí příkazu.
```
kubectl get secrets --namespace kube-system
```
Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který zobrazuje chybovou zprávu, protože uživatel nemá oprávnění pro přístup k tajným kódům:
```
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.
```
Role Azure Kubernetes Service RBAC Reader nemá oprávnění pro přístup k tajným kódům, takže se očekává tato chyba.

Vyžádání přístupu ke clusteru AKS za běhu

Tentokrát můžeme požádat o přístup za běhu jako dočasný Azure Kubernetes Service RBAC Admin pomocí kroků v části Aktivace členství ve skupině nebo vlastnictví ve službě Privileged Identity Management. Informace o tom, jak schválit nebo zamítnout žádosti jako schvalovatele, najdete v tématu Schválení žádostí o aktivaci pro členy skupiny a vlastníky.

Interakce s prostředky clusteru pomocí role správce

Po dočasném Azure Kubernetes Service RBAC Admin přidání role můžete získat přístup k prostředkům clusteru, které vyžadují oprávnění správce.

Pomocí následujícího kubelogin příkazu odeberte existující uložené tokeny:
```
kubelogin remove-tokens
```
Poznámka:

Pokud dojde k chybě kvůli nedostatku oprávnění, přihlaste se a aktualizujte oprávnění pomocí az login příkazu.
Zkuste znovu získat přístup k tajným kódům clusteru kubectl get secrets pomocí příkazu.
```
kubectl get secrets --namespace kube-system
```
Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje tajné kódy v kube-system oboru názvů:
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
Uživatel teď má přístup k tajným kódům, protože má tuto Azure Kubernetes Service RBAC Admin roli.

Aspekty životnosti tokenů

Pokud kvůli návrhu životnosti tokenů udělujete uživatelům, kteří používají nástroje rozhraní příkazového řádku, nebo kubectl kubelogin, doba trvání aktivace technicky nemůže být kratší než 60 minut. I když je doba trvání nastavená na méně než 60 minut, skutečná efektivní doba trvání zůstane mezi 60 až 75 minut.

Když kubelogin se pokusí získat tokeny z platformy Microsoft Identity Platformaccess_token a refresh_token vrátí se k dalšímu použití. Odesílá access_token požadavky na rozhraní API a refresh_token používá se k získání nového access_token , když vyprší platnost aktuálního rozhraní API. Po access_token vygenerování není možné ho odvolat, ale můžete ho refresh_token odvolat. Pokud je odvolán refresh_token , musí uživatel znovu provést ověření, aby získal nový refresh_token. Chcete-li ručně odvolat refresh_token, můžete použít Revoke-AzureADUserAllRefreshToken.

Další kroky

Další informace najdete v následujících článcích:

Sdílet prostřednictvím