Azure RBAC gebruiken in Kubernetes-clusters met Azure Arc (preview)

Artikel
10/24/2023

Kubernetes ClusterRoleBinding- en RoleBinding-objecttypen helpen bij het definiëren van autorisatie in Kubernetes. Met deze functie kunt u Microsoft Entra-id en roltoewijzingen in Azure gebruiken om autorisatiecontroles op het cluster te beheren. Met Azure-roltoewijzingen kunt u nauwkeurig bepalen welke gebruikers Kubernetes-objecten kunnen lezen, schrijven en verwijderen, zoals implementatie, pod en service.

Zie Azure RBAC in Kubernetes met Azure Arc voor een conceptueel overzicht van deze functie.

Belangrijk

Kubernetes Preview-functies met Azure Arc zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. Kubernetes-previews met Azure Arc worden gedeeltelijk gedekt door klantondersteuning op basis van best effort.

Vereisten

Installeer of upgrade de Azure CLI naar de nieuwste versie.
Installeer de nieuwste versie van connectedk8s de Azure CLI-extensie:
```
az extension add --name connectedk8s
```
Als de extensie al is geïnstalleerd, kunt u deze connectedk8s bijwerken naar de nieuwste versie met behulp van de volgende opdracht:
```
az extension update --name connectedk8s
```
Verbind een bestaand door Azure Arc-ingeschakeld Kubernetes-cluster:
- Als u nog geen cluster hebt verbonden, gebruikt u onze quickstart.
- Werk uw agents bij naar de nieuwste versie.

Notitie

U kunt deze functie niet instellen voor Red Hat OpenShift of voor beheerde Kubernetes-aanbiedingen van cloudproviders, zoals Elastic Kubernetes Service of Google Kubernetes Engine, waar de gebruiker geen toegang heeft tot de API-server van het cluster. Voor AKS-clusters (Azure Kubernetes Service) is deze functie systeemeigen beschikbaar en hoeft het AKS-cluster niet te worden verbonden met Azure Arc.

Een servertoepassing maken

Maak een nieuwe Microsoft Entra-toepassing en haal de waarde ervan appId op. Deze waarde wordt in latere stappen gebruikt als 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

Als u API-machtigingen voor aanmelden en lezen van gebruikersprofielen wilt verlenen aan de servertoepassing, kopieert u deze JSON en slaat u deze op in een bestand met de naam 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"
        }
    ]
}

Werk de groepslidmaatschapsclaims van de toepassing bij. Voer de opdrachten uit in dezelfde map als het oauth2-permissions.json bestand. RBAC voor Kubernetes met Azure Arc moet zijn ingesteld op 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}}'

Maak een service-principal en haal de password veldwaarde op. Deze waarde is later vereist, net als serverApplicationSecret wanneer u deze functie inschakelt op het cluster. Dit geheim is standaard één jaar geldig en moet daarna worden gedraaid. Als u een aangepaste verloopduur wilt instellen, gebruikt u 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) 
```
Api-machtigingen voor aanmelden en lezen van gebruikersprofielen verlenen aan de toepassing met behulp van az ad app permission:
```
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
```
Notitie

Een Azure-toepassingsbeheerder moet deze stap uitvoeren.

Voor het gebruik van deze functie in productie raden we u aan een andere servertoepassing te maken voor elk cluster.

Een clienttoepassing maken

Maak een nieuwe Microsoft Entra-toepassing en haal de waarde ervan appId op. Deze waarde wordt in latere stappen gebruikt als 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

Maak een service-principal voor deze clienttoepassing:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

Haal de oAuthPermissionId waarde voor de servertoepassing op:

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

Verdeel de vereiste machtigingen voor de clienttoepassing. RBAC voor Kubernetes met Azure Arc moet zijn ingesteld op 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}}'

Een servertoepassing maken

Maak een nieuwe Microsoft Entra-toepassing en haal de waarde ervan appId op. Deze waarde wordt in latere stappen gebruikt als 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

Werk de groepslidmaatschapsclaims van de toepassing bij:

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

Maak een service-principal en haal de password veldwaarde op. Deze waarde is later vereist, net als serverApplicationSecret wanneer u deze functie inschakelt op het cluster. Dit geheim is standaard één jaar geldig en moet daarna worden gedraaid. Als u een aangepaste verloopduur wilt instellen, gebruikt u 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)
```
Api-machtigingen voor aanmelden en lezen van gebruikersprofielen verlenen aan de toepassing met behulp van az ad app permission:
```
    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 
```
Notitie

Een Azure-toepassingsbeheerder moet deze stap uitvoeren.

Voor het gebruik van deze functie in productie raden we u aan een andere servertoepassing te maken voor elk cluster.

Een clienttoepassing maken

Maak een nieuwe Microsoft Entra-toepassing en haal de waarde ervan appId op. Deze waarde wordt in latere stappen gebruikt als 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

Maak een service-principal voor deze clienttoepassing:
```
az ad sp create --id "${CLIENT_APP_ID}"
```

Haal de oAuthPermissionId waarde voor de servertoepassing op:

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

Geef de vereiste machtigingen voor de clienttoepassing:

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

Een roltoewijzing maken voor de servertoepassing

De servertoepassing heeft de Microsoft.Authorization/*/read machtigingen nodig, zodat deze kan bevestigen dat de gebruiker die de aanvraag indient, is geautoriseerd voor de Kubernetes-objecten die zijn opgenomen in de aanvraag.

Maak een bestand met de naam accessCheck.json met de volgende inhoud:

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

Vervang door <subscription-id> de werkelijke abonnements-id.

Voer de volgende opdracht uit om de nieuwe aangepaste rol te maken:

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

Maak een roltoewijzing op de servertoepassing met assignee behulp van de rol die u hebt gemaakt:

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

Azure RBAC inschakelen in het cluster

Schakel op rollen gebaseerd toegangsbeheer van Azure (RBAC) in op uw Kubernetes-cluster met Azure Arc door de volgende opdracht uit te voeren:

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

Notitie

Voordat u de voorgaande opdracht uitvoert, moet u ervoor zorgen dat het kubeconfig bestand op de computer verwijst naar het cluster waarop u de Azure RBAC-functie inschakelt.

Gebruik --skip-azure-rbac-list deze opdracht met de voorgaande opdracht voor een door komma's gescheiden lijst met gebruikersnamen, e-mailberichten en OpenID-verbindingen die autorisatiecontroles ondergaan met behulp van Systeemeigen ClusterRoleBinding Kubernetes en RoleBinding objecten in plaats van Azure RBAC.

Algemeen cluster waarop geen afstemmingsroutine wordt uitgevoerd op de `apiserver` specificatie

SSH in elk hoofdknooppunt van het cluster en voer de volgende stappen uit:

Als uw kube-apiserver een statische pod is:

Het azure-arc-guard-manifests geheim in de kube-system naamruimte bevat twee bestanden: guard-authn-webhook.yaml en guard-authz-webhook.yaml. Kopieer deze bestanden naar de /etc/guard map van het knooppunt.

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

Open het apiserver manifest in de bewerkingsmodus:

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

Voeg de volgende specificatie toe onder volumes:

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

Voeg de volgende specificatie toe onder volumeMounts:

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

Als uw kube-apiserver een niet-statische pod is:

Open het apiserver manifest in de bewerkingsmodus:

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

Voeg de volgende specificatie toe onder volumes:

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

Voeg de volgende specificatie toe onder volumeMounts:

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

Voeg de volgende apiserver argumenten toe:

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

Als het Kubernetes-cluster versie 1.19.0 of hoger is, moet u ook het volgende apiserver argument instellen:

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

Sla de editor op en sluit deze om de apiserver pod bij te werken.

Cluster gemaakt met behulp van cluster-API

Kopieer het beveiligingsgeheim dat verificatie- en autorisatiewebhookconfiguratiebestanden van het workloadcluster op uw computer bevat:
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
Wijzig het namespace veld in het bestand azure-arc-guard-manifests.yaml in de naamruimte in het beheercluster waarin u de aangepaste resources toepast voor het maken van workloadclusters.

Dit manifest toepassen:

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

Bewerk het object door het KubeadmControlPlane volgende uit te voeren kubectl edit kcp <clustername>-control-plane:

Voeg het volgende fragment toe onder 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"

Voeg het volgende fragment toe onder 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

Voeg het volgende fragment toe onder 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

Sla het object op en sluit het KubeadmControlPlane bij. Wacht tot deze wijzigingen worden weergegeven in het workloadcluster.

Roltoewijzingen maken voor gebruikers voor toegang tot het cluster

Eigenaren van de Kubernetes-resource met Azure Arc kunnen ingebouwde rollen of aangepaste rollen gebruiken om andere gebruikers toegang te verlenen tot het Kubernetes-cluster.

Ingebouwde rollen

Rol	Beschrijving
Azure Arc Kubernetes Viewer	Staat alleen-lezentoegang toe om de meeste objecten in een naamruimte te zien. Deze rol staat het weergeven van geheimen niet toe, omdat `read` machtigingen voor geheimen toegang tot `ServiceAccount` referenties in de naamruimte mogelijk maken. Met deze referenties wordt op zijn beurt API-toegang via die `ServiceAccount` waarde toegestaan (een vorm van escalatie van bevoegdheden).
Azure Arc Kubernetes Writer	Hiermee staat u lees-/schrijftoegang toe tot de meeste objecten in een naamruimte. Deze rol staat het weergeven of wijzigen van rollen of rolbindingen niet toe. Deze rol biedt echter toegang tot geheimen en actieve pods als elke `ServiceAccount` waarde in de naamruimte, zodat deze kan worden gebruikt om de API-toegangsniveaus van elke `ServiceAccount` waarde in de naamruimte te verkrijgen.
Azure Arc Kubernetes-Beheer	Hiermee staat u beheerderstoegang toe. Het is bedoeld om te worden verleend binnen een naamruimte via `RoleBinding`. Als u deze functie gebruikt `RoleBinding`, wordt lees-/schrijftoegang tot de meeste resources in een naamruimte toegestaan, inclusief de mogelijkheid om rollen en rolbindingen in de naamruimte te maken. Met deze rol is schrijftoegang tot het resourcequotum of de naamruimte zelf niet toegestaan.
Azure Arc Kubernetes-cluster Beheer	Hiermee kan superuser elke actie op elke resource uitvoeren. Wanneer u deze gebruikt `ClusterRoleBinding`, krijgt u volledige controle over elke resource in het cluster en in alle naamruimten. Wanneer u deze gebruikt `RoleBinding`, krijgt u volledige controle over elke resource in de naamruimte van de rolbinding, inclusief de naamruimte zelf.

U kunt roltoewijzingen maken die zijn gericht op het Kubernetes-cluster met Azure Arc in Azure Portal in het deelvenster Toegangsbeheer (IAM) van de clusterresource. U kunt ook de volgende Azure CLI-opdrachten gebruiken:

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

In deze opdrachten AZURE-AD-ENTITY-ID kan een gebruikersnaam (bijvoorbeeld testuser@mytenant.onmicrosoft.com) of zelfs de appId waarde van een service-principal zijn.

Hier volgt een ander voorbeeld van het maken van een roltoewijzing die is gericht op een specifieke naamruimte binnen het cluster:

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

Notitie

U kunt roltoewijzingen maken die zijn gericht op het cluster met behulp van Azure Portal of De Azure CLI. Alleen Azure CLI kan echter worden gebruikt voor het maken van roltoewijzingen binnen het bereik van naamruimten.

Aangepaste rollen

U kunt ervoor kiezen om uw eigen roldefinitie te maken voor gebruik in roltoewijzingen.

Doorloop het volgende voorbeeld van een roldefinitie waarmee een gebruiker alleen implementaties kan lezen. Zie de volledige lijst met gegevensacties die u kunt gebruiken om een roldefinitie te maken voor meer informatie.

Kopieer het volgende JSON-object naar een bestand met de naam custom-role.json. Vervang de <subscription-id> tijdelijke aanduiding door de werkelijke abonnements-id. De aangepaste rol maakt gebruik van een van de gegevensacties en stelt u in staat om alle implementaties in het bereik (cluster of naamruimte) weer te geven waar de roltoewijzing wordt gemaakt.

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

Maak de roldefinitie door de volgende opdracht uit te voeren vanuit de map waarin u custom-role.json hebt opgeslagen:
```
az role definition create --role-definition @custom-role.json
```

Maak een roltoewijzing met behulp van deze aangepaste roldefinitie:

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

Kubectl configureren met gebruikersreferenties

Er zijn twee manieren om het kubeconfig-bestand op te halen dat u nodig hebt voor toegang tot het cluster:

U gebruikt het cluster Verbinding maken functie (az connectedk8s proxy) van het Kubernetes-cluster met Azure Arc.
De clusterbeheerder deelt het kubeconfig-bestand met elke andere gebruiker.

Clusterverbinding gebruiken

Voer de volgende opdracht uit om het proxyproces te starten:

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

Nadat het proxyproces is uitgevoerd, kunt u een ander tabblad in de console openen om uw aanvragen naar het cluster te verzenden.

Een gedeeld kubeconfig-bestand gebruiken

Voor het gebruik van een gedeelde kubeconfig zijn enigszins verschillende stappen vereist, afhankelijk van uw Kubernetes-versie.

Kubernetes-versie >= 1.26
Kubernetes < v1.26

Voer de volgende opdracht uit om de referenties voor de gebruiker in te stellen:

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>

Open het kubeconfig-bestand dat u eerder hebt gemaakt. Controleer onder contextsof de context die is gekoppeld aan het cluster verwijst naar de gebruikersreferenties die u in de vorige stap hebt gemaakt. Voer de volgende opdracht uit om de huidige context in te stellen op deze gebruikersreferenties:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Voeg de instelling voor de configuratiemodus toe onderconfig>user:

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

Notitie

Exec-invoegtoepassing is een Kubernetes-verificatiestrategie waarmee u een externe opdracht kunt kubectl uitvoeren om gebruikersreferenties te ontvangen waarnaar moet worden verzonden apiserver. Vanaf Kubernetes versie 1.26 is de standaard-invoegtoepassing voor Azure-autorisatie niet meer opgenomen in client-go en kubectl. Als u met latere versies de exec-invoegtoepassing wilt gebruiken om gebruikersreferenties te ontvangen, moet u Azure Kubelogin gebruiken, een client-go referentie-invoegtoepassing (exec) waarmee Azure-verificatie wordt geïmplementeerd.

Installeer Azure Kubelogin:

Volg de installatie-instructies voor Azure Kubelogin voor Windows of Mac.

Voor Linux of Ubuntu downloadt u de nieuwste versie van kubelogin en voert u vervolgens de volgende opdrachten uit:

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

Converteer de kubelogin om de juiste aanmeldingsmodus te gebruiken. Voor aanmelding met apparaatcode met een Microsoft Entra-gebruiker zijn de opdrachten bijvoorbeeld als volgt:
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig
```

Voer de volgende opdracht uit om de referenties voor de gebruiker in te stellen:

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>

Open het kubeconfig-bestand dat u eerder hebt gemaakt. Controleer onder contextsof de context die is gekoppeld aan het cluster verwijst naar de gebruikersreferenties die u in de vorige stap hebt gemaakt. Voer de volgende opdracht uit om de huidige context in te stellen op deze gebruikersreferenties:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Voeg de instelling voor de configuratiemodus toe onderconfig>user:

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

Aanvragen verzenden naar het cluster

Voer een kubectl opdracht uit. Voorbeeld:
- kubectl get nodes
- kubectl get pods
Nadat u wordt gevraagd om verificatie op basis van een browser, kopieert u de aanmeldings-URL van het apparaat (https://microsoft.com/devicelogin) en opent u deze in uw webbrowser.
Voer de code in die op de console wordt afgedrukt. Kopieer en plak de code op uw terminal in de prompt voor verificatie-invoer van het apparaat.
Voer de gebruikersnaam (testuser@mytenant.onmicrosoft.com) en het bijbehorende wachtwoord in.

Als er een foutbericht als volgt wordt weergegeven, betekent dit dat u niet gemachtigd bent om toegang te krijgen tot de aangevraagde resource:

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.

Een beheerder moet een nieuwe roltoewijzing maken waarmee deze gebruiker toegang heeft tot de resource.

Voorwaardelijke toegang gebruiken met Microsoft Entra-id

Wanneer u Microsoft Entra ID integreert met uw Kubernetes-cluster met Azure Arc, kunt u ook voorwaardelijke toegang gebruiken om de toegang tot uw cluster te beheren.

Notitie

Voorwaardelijke toegang van Microsoft Entra is een Microsoft Entra ID P2-mogelijkheid.

Een voorbeeld van beleid voor voorwaardelijke toegang maken voor gebruik met het cluster:

Zoek en selecteer microsoft Entra-id boven aan De Azure-portal.
Selecteer Bedrijfstoepassingen in het menu voor Microsoft Entra-id aan de linkerkant.
Selecteer Voorwaardelijke toegang in het menu voor bedrijfstoepassingen aan de linkerkant.
Selecteer Beleid>nieuw beleid in het menu voor voorwaardelijke toegang aan de linkerkant.
Voer een naam in voor het beleid, zoals arc-k8s-policy.
Selecteer Gebruikers en groepen. Kies Onder Opnemen de optie Gebruikers en groepen selecteren. Kies vervolgens de gebruikers en groepen waarop u het beleid wilt toepassen. Kies voor dit voorbeeld dezelfde Microsoft Entra-groep met beheerderstoegang tot uw cluster.
Selecteer Cloud-apps of -acties. Kies bij OpnemenApps selecteren. Zoek en selecteer vervolgens de servertoepassing die u eerder hebt gemaakt.
Selecteer Verlenen onder Besturingselementen voor toegang. Selecteer Toegang verlenen>Vereisen dat het apparaat moet worden gemarkeerd als compatibel.
Selecteer onder Beleid inschakelen de optie Maken>.

Open het cluster opnieuw. Voer bijvoorbeeld de kubectl get nodes opdracht uit om knooppunten in het cluster weer te geven:

kubectl get nodes

Volg de instructies om u opnieuw aan te melden. In een foutbericht wordt aangegeven dat u bent aangemeld, maar uw beheerder vereist dat het apparaat dat toegang aanvraagt, wordt beheerd door Microsoft Entra ID om toegang te krijgen tot de resource. Volg vervolgens deze stappen:

Ga in Azure Portal naar Microsoft Entra-id.
Selecteer Enterprise-toepassingen. Selecteer vervolgens onder Activiteit aanmeldingen.
Een vermelding bovenaan toont Mislukt voor status en geslaagd voor voorwaardelijke toegang. Selecteer de vermelding en selecteer vervolgens Voorwaardelijke toegang in Details. U ziet dat uw beleid voor voorwaardelijke toegang wordt vermeld.

Just-In-Time-clustertoegang configureren met Microsoft Entra-id

Een andere optie voor clustertoegangsbeheer is het gebruik van Privileged Identity Management (PIM) voor Just-In-Time-aanvragen.

Notitie

Microsoft Entra PIM is een Microsoft Entra ID P2-mogelijkheid. Zie de prijshandleiding voor meer informatie over Microsoft Entra ID-SKU's.

Voer de volgende stappen uit om Just-In-Time-toegangsaanvragen voor uw cluster te configureren:

Zoek en selecteer microsoft Entra-id boven aan De Azure-portal.
Noteer de tenant-id. Voor de rest van deze instructies verwijzen we naar die id als <tenant-id>.
Selecteer in het menu voor Microsoft Entra-id aan de linkerkant onder Beheren de optie Nieuwe groep groepen>.
Zorg ervoor dat Beveiliging is geselecteerd voor groepstype. Voer een groepsnaam in, zoals myJITGroup. Selecteer Ja onder Microsoft Entra-rollen die aan deze groep (preview) kunnen worden toegewezen. Selecteer Ten slotte Maken.
U gaat terug naar de pagina Groepen . Selecteer de zojuist gemaakte groep en noteer de object-id. Voor de rest van deze instructies verwijzen we naar deze id als <object-id>.
Terug in Azure Portal selecteert u in het menu voor Activiteit aan de linkerkant Privileged Access (preview). Selecteer vervolgens Privileged Access inschakelen.
Selecteer Opdrachten toevoegen om toegang te verlenen.
Selecteer een rol van Lid en selecteer de gebruikers en groepen aan wie u clustertoegang wilt verlenen. Een groepsbeheerder kan deze toewijzingen op elk gewenst moment wijzigen. Wanneer u klaar bent om verder te gaan, selecteert u Volgende.
Kies een toewijzingstype Actief, kies de gewenste duur en geef een reden op. Wanneer u klaar bent om door te gaan, selecteert u Toewijzen. Zie Geschiktheid toewijzen voor een bevoorrechte toegangsgroep (preview) in Privileged Identity Management voor meer informatie over toewijzingstypen.

Nadat u de toewijzingen hebt gemaakt, controleert u of Just-In-Time-toegang werkt door toegang te krijgen tot het cluster. Gebruik bijvoorbeeld de kubectl get nodes opdracht om knooppunten in het cluster weer te geven:

kubectl get nodes

Noteer de verificatievereiste en volg de stappen om te verifiëren. Als de verificatie is geslaagd, ziet u uitvoer die er ongeveer als volgt uit ziet:

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

Het geheim van de servertoepassing vernieuwen

Als het geheim voor de service-principal van de servertoepassing is verlopen, moet u het roteren.

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

Werk het geheim in het cluster bij. Neem eventuele optionele parameters op die u hebt geconfigureerd toen de opdracht oorspronkelijk werd uitgevoerd.

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

Volgende stappen

Maak veilig verbinding met het cluster met behulp van Cluster Verbinding maken.
Lees meer over de architectuur van Azure RBAC in Kubernetes met Arc.

Azure RBAC gebruiken in Kubernetes-clusters met Azure Arc (preview)

Vereisten

Microsoft Entra-toepassingen instellen

Een servertoepassing maken

Een clienttoepassing maken

Een roltoewijzing maken voor de servertoepassing

Azure RBAC inschakelen in het cluster

Algemeen cluster waarop geen afstemmingsroutine wordt uitgevoerd op de apiserver specificatie

Cluster gemaakt met behulp van cluster-API

Roltoewijzingen maken voor gebruikers voor toegang tot het cluster

Ingebouwde rollen

Aangepaste rollen

Kubectl configureren met gebruikersreferenties

Clusterverbinding gebruiken

Een gedeeld kubeconfig-bestand gebruiken

Aanvragen verzenden naar het cluster

Voorwaardelijke toegang gebruiken met Microsoft Entra-id

Just-In-Time-clustertoegang configureren met Microsoft Entra-id

Het geheim van de servertoepassing vernieuwen

Volgende stappen

Aanvullende resources

Algemeen cluster waarop geen afstemmingsroutine wordt uitgevoerd op de `apiserver` specificatie