Använda Azure RBAC i Azure Arc-aktiverade Kubernetes-kluster (förhandsversion)

Artikel
10/24/2023

Kubernetes ClusterRoleBinding- och RoleBinding-objekttyper hjälper till att definiera auktorisering i Kubernetes internt. Med den här funktionen kan du använda Microsoft Entra-ID och rolltilldelningar i Azure för att kontrollera auktoriseringskontroller i klustret. Med Azure-rolltilldelningar kan du detaljstyra vilka användare som kan läsa, skriva och ta bort Kubernetes-objekt som distribution, podd och tjänst.

En konceptuell översikt över den här funktionen finns i Azure RBAC på Azure Arc-aktiverade Kubernetes.

Viktigt!

Förhandsversionsfunktioner i Azure Arc-aktiverade Kubernetes är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. Förhandsversioner av Azure Arc-aktiverade Kubernetes omfattas delvis av kundsupport på bästa sätt.

Förutsättningar

Installera eller uppgradera Azure CLI till den senaste versionen.
Installera den senaste versionen av connectedk8s Azure CLI-tillägget:
```
az extension add --name connectedk8s
```
connectedk8s Om tillägget redan är installerat kan du uppdatera det till den senaste versionen med hjälp av följande kommando:
```
az extension update --name connectedk8s
```
Anslut ett befintligt Azure Arc-:aktiverat Kubernetes-kluster:
- Om du inte har anslutit ett kluster ännu kan du använda vår snabbstart.
- Uppgradera dina agenter till den senaste versionen.

Kommentar

Du kan inte konfigurera den här funktionen för Red Hat OpenShift eller för hanterade Kubernetes-erbjudanden från molnleverantörer som Elastic Kubernetes Service eller Google Kubernetes Engine där användaren inte har åtkomst till API-servern i klustret. För AKS-kluster (Azure Kubernetes Service) är den här funktionen tillgänglig internt och kräver inte att AKS-klustret är anslutet till Azure Arc.

Skapa ett serverprogram

Skapa ett nytt Microsoft Entra-program och hämta dess appId värde. Det här värdet används i senare steg som serverApplicationId.

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

Om du vill ge API-behörigheterna "Logga in och läsa användarprofil" till serverprogrammet kopierar du den här JSON:n och sparar den i en fil med namnet 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"
        }
    ]
}

Uppdatera programmets gruppmedlemskapsanspråk. Kör kommandona i samma katalog som oauth2-permissions.json filen. RBAC för Azure Arc-aktiverade Kubernetes måste anges till AzureADMyOrg:signInAudience

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}}'

Skapa ett huvudnamn för tjänsten och hämta dess password fältvärde. Det här värdet krävs senare som serverApplicationSecret när du aktiverar den här funktionen i klustret. Den här hemligheten är giltig i ett år som standard och måste roteras efter det. Om du vill ange en anpassad förfallotid använder du az ad sp credential reset:
```
az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv) 
```
Ge "Logga in och läs användarprofil" API-behörigheter till programmet med hjälp az ad app permissionav :
```
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
```
Kommentar

En Azure-programadministratör måste köra det här steget.

För användning av den här funktionen i produktion rekommenderar vi att du skapar ett annat serverprogram för varje kluster.

Skapa ett klientprogram

Skapa ett nytt Microsoft Entra-program och hämta dess appId värde. Det här värdet används i senare steg som clientApplicationId.

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

Skapa ett huvudnamn för tjänsten för det här klientprogrammet:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

oAuthPermissionId Hämta värdet för serverprogrammet:

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

Bevilja nödvändiga behörigheter för klientprogrammet. RBAC för Azure Arc-aktiverade Kubernetes måste anges till AzureADMyOrg:signInAudience

    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}}'

Skapa ett serverprogram

Skapa ett nytt Microsoft Entra-program och hämta dess appId värde. Det här värdet används i senare steg som serverApplicationId.

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

Uppdatera programmets gruppmedlemskapsanspråk:

az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All

Skapa ett huvudnamn för tjänsten och hämta dess password fältvärde. Det här värdet krävs senare som serverApplicationSecret när du aktiverar den här funktionen i klustret. Den här hemligheten är giltig i ett år som standard och måste roteras efter det. Om du vill ange en anpassad förfallotid använder du az ad sp credential reset:
```
    az ad sp create --id "${SERVER_APP_ID}"
    SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)
```
Ge "Logga in och läs användarprofil" API-behörigheter till programmet med hjälp az ad app permissionav :
```
    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 
```
Kommentar

En Azure-programadministratör måste köra det här steget.

För användning av den här funktionen i produktion rekommenderar vi att du skapar ett annat serverprogram för varje kluster.

Skapa ett klientprogram

Skapa ett nytt Microsoft Entra-program och hämta dess appId värde. Det här värdet används i senare steg som clientApplicationId.

CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --native-app --reply-urls "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

Skapa ett huvudnamn för tjänsten för det här klientprogrammet:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

oAuthPermissionId Hämta värdet för serverprogrammet:

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

Bevilja de behörigheter som krävs för klientprogrammet:

az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
az ad app permission grant --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}"

Skapa en rolltilldelning för serverprogrammet

Serverprogrammet behöver behörigheterna Microsoft.Authorization/*/read så att det kan bekräfta att användaren som gör begäran har behörighet för Kubernetes-objekten som ingår i begäran.

Skapa en fil med namnet accessCheck.json med följande innehåll:

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

Ersätt <subscription-id> med det faktiska prenumerations-ID:t.

Kör följande kommando för att skapa den nya anpassade rollen:

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

Skapa en rolltilldelning i serverprogrammet som assignee med hjälp av den roll som du skapade:

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

Aktivera Azure RBAC i klustret

Aktivera rollbaserad åtkomstkontroll i Azure (RBAC) i ditt Azure Arc-aktiverade Kubernetes-kluster genom att köra följande kommando:

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

Kommentar

Innan du kör föregående kommando kontrollerar du att kubeconfig filen på datorn pekar på klustret där du aktiverar Azure RBAC-funktionen.

Använd --skip-azure-rbac-list med föregående kommando för en kommaavgränsad lista över användarnamn, e-postmeddelanden och OpenID-anslutningar som genomgår auktoriseringskontroller med kubernetes native ClusterRoleBinding och RoleBinding objekt i stället för Azure RBAC.

Generiskt kluster där ingen avstämning körs på specifikationen `apiserver`

SSH till varje huvudnod i klustret och utför följande steg:

Om din kube-apiserver är en statisk podd:

Hemligheten azure-arc-guard-manifestskube-system i namnområdet innehåller två filer: guard-authn-webhook.yaml och guard-authz-webhook.yaml. Kopiera dessa filer till /etc/guard nodens katalog.

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

Öppna manifestet apiserver i redigeringsläge:

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

Lägg till följande specifikation under volumes:

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

Lägg till följande specifikation under volumeMounts:

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

Om din kube-apiserver inte är en statisk podd:

Öppna manifestet apiserver i redigeringsläge:

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

Lägg till följande specifikation under volumes:

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

Lägg till följande specifikation under volumeMounts:

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

Lägg till följande apiserver argument:

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

Om Kubernetes-klustret är version 1.19.0 eller senare måste du också ange följande apiserver argument:

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

Spara och stäng redigeraren för att uppdatera apiserver podden.

Kluster som skapats med hjälp av kluster-API

Kopiera skyddshemligheten som innehåller webhookskonfigurationsfiler för autentisering och auktorisering från arbetsbelastningsklustret till datorn:
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
Ändra fältet namespace i filen azure-arc-guard-manifests.yaml till namnområdet i hanteringsklustret där du använder de anpassade resurserna för att skapa arbetsbelastningskluster.

Använd det här manifestet:

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

Redigera objektet KubeadmControlPlane genom att köra kubectl edit kcp <clustername>-control-plane:

Lägg till följande kodfragment under files:

- 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"

Lägg till följande kodfragment under apiServer>extraVolumes:

- 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

Lägg till följande kodfragment under apiServer>extraArgs:

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

Spara och stäng för att uppdatera objektet KubeadmControlPlane . Vänta tills ändringarna visas i arbetsbelastningsklustret.

Skapa rolltilldelningar för användare för åtkomst till klustret

Ägare av Den Azure Arc-aktiverade Kubernetes-resursen kan använda antingen inbyggda roller eller anpassade roller för att ge andra användare åtkomst till Kubernetes-klustret.

Inbyggda roller

Roll	beskrivning
Azure Arc Kubernetes Viewer	Tillåter skrivskyddad åtkomst för att se de flesta objekt i ett namnområde. Den här rollen tillåter inte visning av hemligheter eftersom `read` behörighet för hemligheter skulle ge åtkomst till `ServiceAccount` autentiseringsuppgifter i namnområdet. Dessa autentiseringsuppgifter skulle i sin tur tillåta API-åtkomst via det `ServiceAccount` värdet (en form av behörighetseskalering).
Azure Arc Kubernetes Writer	Tillåter läs-/skrivåtkomst till de flesta objekt i ett namnområde. Den här rollen tillåter inte visning eller ändring av roller eller rollbindningar. Den här rollen tillåter dock åtkomst till hemligheter och poddar som valfritt `ServiceAccount` värde i namnområdet, så den kan användas för att få API-åtkomstnivåerna för valfritt `ServiceAccount` värde i namnområdet.
Azure Arc Kubernetes-administratör	Tillåter administratörsåtkomst. Det är avsett att beviljas inom ett namnområde via `RoleBinding`. Om du använder den i `RoleBinding`tillåter den läs-/skrivåtkomst till de flesta resurser i ett namnområde, inklusive möjligheten att skapa roller och rollbindningar i namnområdet. Den här rollen tillåter inte skrivåtkomst till resurskvoten eller till själva namnområdet.
Azure Arc Kubernetes-klusteradministratör	Tillåter superanvändaråtkomst för att köra alla åtgärder på alla resurser. När du använder den i `ClusterRoleBinding`ger den fullständig kontroll över varje resurs i klustret och i alla namnområden. När du använder den i `RoleBinding`ger den fullständig kontroll över varje resurs i rollbindningens namnområde, inklusive själva namnområdet.

Du kan skapa rolltilldelningar som är begränsade till Det Azure Arc-aktiverade Kubernetes-klustret i Azure-portalen i fönstret Åtkomstkontroll (IAM) i klusterresursen. Du kan också använda följande Azure CLI-kommandon:

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

I dessa kommandon kan vara ett användarnamn (till exempel testuser@mytenant.onmicrosoft.com) eller till och med värdet för appId tjänstens AZURE-AD-ENTITY-ID huvudnamn.

Här är ett annat exempel på hur du skapar en rolltilldelning som är begränsad till ett specifikt namnområde i klustret:

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

Kommentar

Du kan skapa rolltilldelningar som är begränsade till klustret med hjälp av antingen Azure-portalen eller Azure CLI. Endast Azure CLI kan dock användas för att skapa rolltilldelningar som är begränsade till namnområden.

Anpassade roller

Du kan välja att skapa en egen rolldefinition för användning i rolltilldelningar.

Gå igenom följande exempel på en rolldefinition som gör att en användare endast kan läsa distributioner. Mer information finns i den fullständiga listan över dataåtgärder som du kan använda för att konstruera en rolldefinition.

Kopiera följande JSON-objekt till en fil med namnet custom-role.json. <subscription-id> Ersätt platshållaren med det faktiska prenumerations-ID:t. Den anpassade rollen använder en av dataåtgärderna och låter dig visa alla distributioner i omfånget (kluster eller namnområde) där rolltilldelningen skapas.

{
    "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>"
    ]
}

Skapa rolldefinitionen genom att köra följande kommando från mappen där du sparade custom-role.json:
```
az role definition create --role-definition @custom-role.json
```

Skapa en rolltilldelning med den här anpassade rolldefinitionen:

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

Konfigurera kubectl med användarautentiseringsuppgifter

Det finns två sätt att hämta kubeconfig-filen som du behöver för att komma åt klustret:

Du använder klustrets Anslut funktion (az connectedk8s proxy) i Det Azure Arc-aktiverade Kubernetes-klustret.
Klusteradministratören delar kubeconfig-filen med alla andra användare.

Använda klusteranslutning

Kör följande kommando för att starta proxyprocessen:

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

När proxyprocessen har körts kan du öppna en annan flik i konsolen för att börja skicka dina begäranden till klustret.

Använda en delad kubeconfig-fil

Att använda en delad kubeconfig kräver lite olika steg beroende på din Kubernetes-version.

Kubernetes-version >= 1.26
Kubernetes < v1.26

Kör följande kommando för att ange autentiseringsuppgifterna för användaren:

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>

Öppna kubeconfig-filen som du skapade tidigare. Under contextskontrollerar du att kontexten som är associerad med klustret pekar på de användarautentiseringsuppgifter som du skapade i föregående steg. Om du vill ange den aktuella kontexten till dessa användarautentiseringsuppgifter kör du följande kommando:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Lägg till konfigurationslägesinställningen under 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

Kommentar

Exec-plugin-programmet är en Kubernetes-autentiseringsstrategi som gör det möjligt kubectl att köra ett externt kommando för att ta emot användarautentiseringsuppgifter som ska skickas till apiserver. Från och med Kubernetes version 1.26 ingår inte längre standardprogrammet för Azure-auktorisering i client-go och kubectl. För att kunna använda exec-plugin-programmet för att ta emot autentiseringsuppgifter för användare måste du använda Azure Kubelogin, ett client-go plugin-program för autentiseringsuppgifter (exec) som implementerar Azure-autentisering.

Installera Azure Kubelogin:

För Windows eller Mac följer du installationsanvisningarna för Azure Kubelogin.

För Linux eller Ubuntu laddar du ned den senaste versionen av kubelogin och kör sedan följande kommandon:

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

Konvertera kubelogin till att använda lämpligt inloggningsläge. För inloggning med enhetskod med en Microsoft Entra-användare skulle kommandona till exempel vara följande:
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig
```

Kör följande kommando för att ange autentiseringsuppgifterna för användaren:

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>

Öppna kubeconfig-filen som du skapade tidigare. Under contextskontrollerar du att kontexten som är associerad med klustret pekar på de användarautentiseringsuppgifter som du skapade i föregående steg. Om du vill ange den aktuella kontexten till dessa användarautentiseringsuppgifter kör du följande kommando:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Lägg till konfigurationslägesinställningen under 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

Skicka begäranden till klustret

Kör valfritt kubectl kommando. Till exempel:
- kubectl get nodes
- kubectl get pods
När du har tillfrågats om webbläsarbaserad autentisering kopierar du url:en för enhetsinloggning (https://microsoft.com/devicelogin) och öppnar den i webbläsaren.
Ange koden som skrivs ut på konsolen. Kopiera och klistra in koden i terminalen i kommandotolken för indata för enhetsautentisering.
Ange användarnamnet (testuser@mytenant.onmicrosoft.com) och det associerade lösenordet.

Om du ser ett felmeddelande som det här innebär det att du inte har åtkomst till den begärda resursen:

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.

En administratör måste skapa en ny rolltilldelning som ger användaren åtkomst till resursen.

Använda villkorlig åtkomst med Microsoft Entra-ID

När du integrerar Microsoft Entra-ID med ditt Azure Arc-aktiverade Kubernetes-kluster kan du också använda villkorsstyrd åtkomst för att styra åtkomsten till klustret.

Kommentar

Villkorsstyrd åtkomst för Microsoft Entra är en Microsoft Entra ID P2-funktion.

Så här skapar du ett exempel på en princip för villkorsstyrd åtkomst som ska användas med klustret:

Överst i Azure-portalen söker du efter och väljer Microsoft Entra-ID.
På menyn för Microsoft Entra-ID till vänster väljer du Företagsprogram.
På menyn för företagsprogram till vänster väljer du Villkorlig åtkomst.
På menyn för Villkorlig åtkomst till vänster väljer du Principer>Ny princip.
Ange ett namn för principen, till exempel arc-k8s-policy.
Välj Användare och grupper. Under Inkludera väljer du Välj användare och grupper. Välj sedan de användare och grupper där du vill tillämpa principen. I det här exemplet väljer du samma Microsoft Entra-grupp som har administrativ åtkomst till klustret.
Välj Molnappar eller åtgärder. Under Inkludera väljer du Välj appar. Sök sedan efter och välj det serverprogram som du skapade tidigare.
Under Åtkomstkontroller väljer du Bevilja. Välj Bevilja åtkomst>Kräv att enheten markeras som kompatibel.
Under Aktivera princip väljer du På>Skapa.

Få åtkomst till klustret igen. Kör till exempel kubectl get nodes kommandot för att visa noder i klustret:

kubectl get nodes

Följ anvisningarna för att logga in igen. Ett felmeddelande anger att du har loggat in, men administratören kräver att enheten som begär åtkomst hanteras av Microsoft Entra-ID för att få åtkomst till resursen. Följ dessa steg:

Gå till Microsoft Entra-ID i Azure-portalen.
Välj Företagsprogram. Under Aktivitet väljer du Inloggningar.
En post högst upp visar Misslyckades för Status och Lyckades för villkorsstyrd åtkomst. Välj posten och välj sedan Villkorsstyrd åtkomst i Information. Observera att principen för villkorsstyrd åtkomst visas.

Konfigurera just-in-time-klusteråtkomst med Microsoft Entra-ID

Ett annat alternativ för klusteråtkomstkontroll är att använda Privileged Identity Management (PIM) för just-in-time-begäranden.

Kommentar

Microsoft Entra PIM är en Microsoft Entra ID P2-funktion. Mer information om SKU:er för Microsoft Entra-ID finns i prisguiden.

Utför följande steg för att konfigurera just-in-time-åtkomstbegäranden för klustret:

Överst i Azure-portalen söker du efter och väljer Microsoft Entra-ID.
Anteckna klientorganisations-ID:t. För resten av dessa instruktioner refererar vi till det ID:t som <tenant-id>.
På menyn för Microsoft Entra-ID till vänster går du till Hantera och väljer Grupper>Ny grupp.
Kontrollera att Säkerhet har valts för Grupptyp. Ange ett gruppnamn, till exempel myJITGroup. Under Microsoft Entra-roller kan tilldelas till den här gruppen (förhandsversion) väljer du Ja. Välj slutligen Skapa.
Du kommer tillbaka till sidan Grupper . Välj den nyligen skapade gruppen och anteckna objekt-ID:t. För resten av dessa instruktioner refererar vi till det här ID:t som <object-id>.
I Azure-portalen går du till menyn för Aktivitet till vänster och väljer Privilegierad åtkomst (förhandsversion). Välj sedan Aktivera privilegierad åtkomst.
Välj Lägg till tilldelningar för att börja bevilja åtkomst.
Välj rollen Medlem och välj de användare och grupper som du vill bevilja klusteråtkomst till. En gruppadministratör kan när som helst ändra dessa tilldelningar. När du är redo att gå vidare väljer du Nästa.
Välj en tilldelningstyp av Aktiv, välj önskad varaktighet och ange en motivering. När du är redo att fortsätta väljer du Tilldela. Mer information om tilldelningstyper finns i Tilldela berättigande för en privilegierad åtkomstgrupp (förhandsversion) i Privileged Identity Management.

När du har gjort tilldelningarna kontrollerar du att just-in-time-åtkomst fungerar genom att komma åt klustret. Använd kubectl get nodes till exempel kommandot för att visa noder i klustret:

kubectl get nodes

Observera autentiseringskravet och följ stegen för att autentisera. Om autentiseringen lyckas bör du se utdata som liknar följande:

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

Uppdatera hemligheten för serverprogrammet

Om hemligheten för serverprogrammets tjänsthuvudnamn har upphört att gälla måste du rotera den.

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

Uppdatera hemligheten i klustret. Inkludera valfria parametrar som du konfigurerade när kommandot kördes ursprungligen.

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

Nästa steg

Anslut till klustret på ett säkert sätt med hjälp av kluster Anslut.
Läs mer om arkitekturen för Azure RBAC på Arc-aktiverade Kubernetes.

Använda Azure RBAC i Azure Arc-aktiverade Kubernetes-kluster (förhandsversion)

Förutsättningar

Konfigurera Microsoft Entra-program

Skapa ett serverprogram

Skapa ett klientprogram

Skapa en rolltilldelning för serverprogrammet

Aktivera Azure RBAC i klustret

Generiskt kluster där ingen avstämning körs på specifikationen apiserver

Kluster som skapats med hjälp av kluster-API

Skapa rolltilldelningar för användare för åtkomst till klustret

Inbyggda roller

Anpassade roller

Konfigurera kubectl med användarautentiseringsuppgifter

Använda klusteranslutning

Använda en delad kubeconfig-fil

Skicka begäranden till klustret

Använda villkorlig åtkomst med Microsoft Entra-ID

Konfigurera just-in-time-klusteråtkomst med Microsoft Entra-ID

Uppdatera hemligheten för serverprogrammet

Nästa steg

Ytterligare resurser

Generiskt kluster där ingen avstämning körs på specifikationen `apiserver`