Utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure sur des clusters Kubernetes avec Azure Arc

Article
10/16/2024

Les types d’objets Kubernetes ClusterRoleBinding et RoleBinding permettent de définir l’autorisation dans Kubernetes en mode natif. Avec cette fonctionnalité, vous pouvez utiliser Microsoft Entra ID et les attributions de rôles Azure pour contrôler les vérifications des autorisations sur le cluster. Les attributions de rôles Azure vous permettent de contrôler précisément quels utilisateurs peuvent lire, écrire et supprimer les objets Kubernetes tels que les déploiements, les pods et les services.

Pour obtenir une vue d’ensemble conceptuelle de cette fonctionnalité, consultez Azure RBAC sur Kubernetes avec Azure Arc.

Prérequis

Installez ou mettez à niveau Azure CLI vers la dernière version.
Installez la dernière version de l’extension Azure CLI connectedk8s :
```
az extension add --name connectedk8s
```
Si l'extension connectedk8s est déjà installée, vous pouvez la mettre à jour vers la version la plus récente à l'aide de la commande suivante :
```
az extension update --name connectedk8s
```
Connectez un cluster Kubernetes avec Azure Arc existant :
- Si vous n’avez pas encore connecté de cluster, utilisez notre démarrage rapide.
- Mettez à niveau vos agents vers la dernière version.

Remarque

Azure RBAC n’est pas disponible pour des offres Kubernetes managées ou Red Hat OpenShift où l’accès utilisateur au serveur d’API est restreint (par exemple, Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)).

Azure RBAC ne prend actuellement pas en compte les clusters Kubernetes fonctionnant sur une architecture ARM64. Veuillez utiliser Kubernetes RBAC pour gérer le contrôle d’accès pour des clusters Kubernetes ARM64.

Pour les clusters Azure Kubernetes service (AKS), cette fonctionnalité est disponible en mode natif et ne nécessite pas que le cluster AKS soit connecté à Azure Arc.

Pour les clusters Azure Kubernetes Service (AKS) avec Azure Arc sur Azure Stack HCI 23H2, l’activation d’Azure RBAC est à l’heure actuelle uniquement prise en charge pendant la création du cluster Kubernetes. Pour créer un cluster AKS avec Azure Arc sur lequel Azure RBAC est activé, suivez le guide Utiliser l’autorisation Azure RBAC pour Kubernetes. Notez qu’Azure RBAC n’est pas pris en charge pour Azure Stack HCI, version 22H2.

Activer Azure RBAC sur le cluster

Obtenez l’identité du MSI de cluster en exécutant la commande suivante :
```
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
```
Récupérez l’ID (identity.principalId) de la sortie et exécutez la commande suivante pour attribuer le rôle Lecteur CheckAccess d’identité managée de cluster connectée au MSI de cluster :
```
az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
```
Activez le contrôle d’accès en fonction du rôle d’Azure (RBAC) sur votre cluster Kubernetes avec Azure Arc en exécutant la commande suivante :
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
Remarque

Avant d’exécuter la commande précédente, assurez-vous que le fichier kubeconfig sur l’ordinateur pointe sur le cluster sur lequel vous allez activer la fonctionnalité Azure RBAC.

Utilisez --skip-azure-rbac-list avec la commande précédente pour obtenir une liste séparée par des virgules de noms d’utilisateur, adresses de messagerie, et connexions OpenID en cours de vérification des autorisations à l’aide des objets Kubernetes natifs ClusterRoleBinding et RoleBinding à la place d’Azure RBAC.

Cluster générique dans lequel aucun réconciliateur n’est en cours d’exécution sur la spécification `apiserver`

Utilisez SSH dans chaque nœud principal du cluster et suivez les étapes suivantes :

Si votre kube-apiserver est un Pod statique:

Le secret azure-arc-guard-manifests dans l’espace de noms kube-system contient deux fichiers : guard-authn-webhook.yaml et guard-authz-webhook.yaml. Copiez ces fichiers dans le répertoire /etc/guard du nœud.

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

Ouvrez le manifeste apiserver en mode édition :

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

Utilisez la spécification suivante sous volumes :

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

Utilisez la spécification suivante sous volumeMounts :

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

Si votre kube-apiserver n’est pas un pod statique :

Ouvrez le manifeste apiserver en mode édition :

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

Utilisez la spécification suivante sous volumes :

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

Utilisez la spécification suivante sous volumeMounts :

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

Ajoutez les arguments apiserver suivants :

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

Si le cluster Kubernetes est de version 1.19.0 ou ultérieure, vous devez également définir l'argument apiserver suivant :

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

Enregistrez et fermez l’éditeur pour mettre à jour le pod apiserver.

Cluster créé à l’aide de l’API Cluster

Copiez le secret de protection qui contient les fichiers de configuration webhook d’authentification et d’autorisation à partir du cluster de charge de travail sur votre ordinateur :
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
Remplacez le champ namespace du fichier azure-arc-guard-manifests.yaml par l’espace de noms dans le cluster de gestion dans lequel vous appliquez les ressources personnalisées pour la création de clusters de charge de travail.

Appliquez ce manifeste :

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

Modifiez l’objet KubeadmControlPlane en exécutant kubectl edit kcp <clustername>-control-plane :

Ajoutez l’extrait de code suivant sous 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"

Ajoutez l’extrait de code suivant sous 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

Ajoutez l’extrait de code suivant sous 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

Enregistrez et fermez pour mettre à jour l’objet KubeadmControlPlane. Attendez que ces modifications apparaissent sur le cluster de charge de travail.

Créer des attributions de rôles pour permettre aux utilisateurs d’accéder au cluster

Les propriétaires de la ressource Kubernetes avec Azure Arc peuvent utiliser les rôles intégrés ou des rôles personnalisés pour accorder à d’autres utilisateurs l’accès au cluster Kubernetes.

Rôles intégrés

Rôle	Description
Visionneuse Kubernetes Azure Arc	Autorise l’accès en lecture seule pour voir la plupart des objets dans un espace de noms. Ce rôle n’autorise pas l’affichage des secrets parce qu’une autorisation `read` sur les secrets donnerait accès aux informations d’identification `ServiceAccount` dans l’espace de noms. Ces informations d’identification autorisent à leur tour l’accès à l’API par le biais de cette valeur `ServiceAccount` (une forme d’élévation des privilèges).
Enregistreur Kubernetes Azure Arc	Autorise l’accès en lecture/écriture pour la plupart des objets dans un espace de noms. Ce rôle n’autorise pas l’affichage ni la modification des rôles et des liaisons de rôles. Toutefois, ce rôle permet d’accéder aux secrets et aux pods en cours d’exécution comme n’importe quelle valeur `ServiceAccount` de l’espace de noms. Il peut donc être utilisé pour obtenir les niveaux d’accès API de n’importe quelle valeur `ServiceAccount` dans l’espace de noms.
Administrateur Kubernetes Azure Arc	Autorise l’accès administrateur. C’est normalement accordé au sein d’un espace de noms via `RoleBinding`. Si vous l’utilisez dans `RoleBinding`, il autorise l’accès en lecture/écriture à la plupart des ressources dans un espace de noms, y compris la possibilité de créer des rôles et des liaisons de rôles dans l’espace de noms. Ce rôle n’autorise pas l’accès en écriture au quota de ressources ou à l’espace de noms lui-même.
Administrateur de cluster Kubernetes Azure Arc	Autorise l’accès de super utilisateur qui permet d’exécuter n’importe quelle action sur toutes les ressources. Quand vous l’utilisez dans `ClusterRoleBinding`, il donne un contrôle total sur l’ensemble des ressources dans le cluster et dans tous les espaces de noms. Quand vous l’utilisez dans `RoleBinding`, il offre un contrôle total sur chaque ressource dans l’espace de noms de la liaison de rôle, y compris l’espace de noms lui-même.

Vous pouvez créer des attributions de rôles limitées au cluster Kubernetes avec Azure Arc dans le portail Azure sur le panneau de contrôle d’accès (IAM) de la ressource de cluster. Vous pouvez également utiliser les commandes Azure CLI suivantes :

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

Dans ces commandes, AZURE-AD-ENTITY-ID peut être un nom d’utilisateur (par exemple, testuser@mytenant.onmicrosoft.com) ou même la valeur appId d’un principal de service.

Voici un autre exemple de création d’une attribution de rôle étendue à un espace de noms spécifique au sein du cluster :

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

Remarque

Vous pouvez créer des affectations de rôles pour le cluster en utilisant le portail Azure ou l’Azure CLI. Toutefois, seul Azure CLI peut être utilisé pour créer des attributions de rôles limitées à des espaces de noms.

Rôles personnalisés

Vous pouvez choisir de créer votre propre définition de rôle pour utilisation dans les attributions de rôles.

Examinez en détail l’exemple suivant de définition de rôle qui permet à un utilisateur de lire uniquement les déploiements. Pour plus d’informations, consultez la liste complète des actions de données que vous pouvez utiliser pour créer une définition de rôle.

Copiez l’objet JSON ci-dessous dans un fichier appelé custom-role.js. Remplacez l’espace réservé <subscription-id> par l’ID réel de l’abonnement. Le rôle personnalisé utilise l’une des actions de données et vous permet de voir tous les déploiements dans l’étendue (cluster ou espace de noms) où l’attribution de rôle est créée.

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

Créez la définition de rôle en exécutant la commande suivante à partir du dossier où vous avez enregistré custom-role.json :
```
az role definition create --role-definition @custom-role.json
```

Créez une attribution de rôle à l’aide de cette définition de rôle personnalisée :

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

Configurer kubectl avec les informations d’identification de l’utilisateur

Il existe deux manières d’accéder au fichier kubeconfig dont vous avez besoin pour accéder au cluster :

Vous utilisez la fonctionnalité de connexion de cluster (az connectedk8s proxy) du cluster Kubernetes avec Azure Arc.
L’administrateur du cluster partage le fichier kubeconfig avec tous les autres utilisateurs.

Utiliser la connexion au cluster

Exécutez la commande suivante pour démarrer le processus proxy :

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

Une fois le processus de proxy en cours d’exécution, vous pouvez ouvrir un autre onglet dans votre console pour commencer à envoyer vos demandes au cluster.

Utiliser un fichier kubeconfig partagé

L’utilisation d’un kubeconfig partagé nécessite des étapes légèrement différentes en fonction de votre version de Kubernetes.

Version de Kubernetes >= 1.26
Kubernetes < v1.26

Exécutez la commande suivante pour définir les informations d’identification de l’utilisateur. Spécifiez serverApplicationId en tant que 6256c85f-0aad-4d50-b960-e6e9b21efe35 et clientApplicationId comme 3f4439ff-e698-4d6d-84fe-09c9d574f06b :

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>

Ouvrez le fichier kubeconfig que vous avez créé plus tôt. Sous contexts, vérifiez que le contexte associé aux points du cluster pointe vers les informations d’identification de l’utilisateur que vous avez créées à l’étape précédente. Pour définir le contexte actuel sur ces informations d’identification utilisateur, exécutez la commande suivante :
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```
Ajoutez le paramètre config-mode sous 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
```
Remarque

Le plug-in Exec est une stratégie d’authentification Kubernetes qui permet à kubectl d’exécuter une commande externe pour recevoir les informations d’identification utilisateur à envoyer à apiserver. À compter de Kubernetes version 1.26, le plug-in d’autorisation Azure par défaut n’est plus inclus dans client-go et kubectl. Avec les versions ultérieures, pour utiliser le plug-in exec afin de recevoir les informations d’identification utilisateur, vous devez faire appel à Azure Kubelogin, un plug-in d’informations d’identification client-go (exec) qui implémente l’authentification Azure.

Installez Azure Kubelogin :

Pour Windows ou Mac, suivez les instructions d’installation Azure Kubelogin.

Pour Linux ou Ubuntu, téléchargez la dernière version de kubelogin, puis exécutez les commandes suivantes :

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

Kubelogin peut être utilisé pour s’authentifier auprès des clusters Azure Arc en demandant un jeton de preuve de possession (PoP). Convertissez le kubeconfig à l’aide de kubelogin pour utiliser le mode de connexion approprié. Par exemple, pour le mode de connexion Code d’appareil avec un utilisateur Microsoft Entra, les commandes sont les suivantes :
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
```

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>

Ouvrez le fichier kubeconfig que vous avez créé plus tôt. Sous contexts, vérifiez que le contexte associé aux points du cluster pointe vers les informations d’identification de l’utilisateur que vous avez créées à l’étape précédente. Pour définir le contexte actuel sur ces informations d’identification utilisateur, exécutez la commande suivante :
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Ajoutez le paramètre config-mode sous 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

Envoyez les requêtes au cluster

Exécutez une commande kubectl. Par exemple :
- kubectl get nodes
- kubectl get pods
Après avoir été invité à fournir une authentification basée sur le navigateur, copiez l’URL de connexion de l’appareil (https://microsoft.com/devicelogin) et ouvrez votre navigateur web.
Entrez le code imprimé sur votre console. Copiez et collez le code sur votre terminal dans l’invite d’entrée d’authentification de l’appareil.
Entrez le nom d’utilisateur (testuser@mytenant.onmicrosoft.com) et le mot de passe associé.
Si vous voyez un message d’erreur semblable à celui-ci, cela signifie que vous n’êtes pas autorisé à accéder à la ressource demandée :
```
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.
```
Un administrateur doit créer une nouvelle attribution de rôle qui autorise cet utilisateur à accéder à la ressource.

Utiliser l’accès conditionnel avec Microsoft Entra ID

Quand vous intégrez Microsoft Entra ID à votre cluster Kubernetes avec Azure Arc, vous pouvez également utiliser l’accès conditionnel pour contrôler l’accès à votre cluster.

Remarque

L’accès conditionnel Microsoft Entra, est une fonctionnalité Microsoft Entra ID P2.

Pour créer un exemple de stratégie d’accès conditionnel à utiliser avec le cluster :

En haut du portail Azure, recherchez et sélectionnez Microsoft Entra ID.
Dans le menu Microsoft Entra ID sur le côté gauche, sélectionnez Applications d’entreprise.
Dans le menu Applications d’entreprise sur le côté gauche, sélectionnez Accès conditionnel.
Sur le menu Accès conditionnel sur le côté gauche, sélectionnez Stratégies>Nouvelle stratégie.
Entrez le nom de la stratégie, par exemple arc-k8s-policy.
Sélectionnez Utilisateurs et groupes. Sous Inclure, choisissez Sélectionner les utilisateurs et les groupes. Choisissez ensuite les utilisateurs et les groupes auxquels vous souhaitez appliquer la stratégie. Pour cet exemple, choisissez le même groupe Microsoft Entra qui a un accès administratif à votre cluster.
Sélectionnez Applications ou actions cloud. Sous Inclure, choisissez Sélectionner les applications. Ensuite, recherchez et sélectionnez l’application serveur que vous avez créée précédemment.
Sous Contrôles d’accès, sélectionnez Accorder. Sélectionnez Accorder l’accès>Exiger que l’appareil soit marqué comme conforme.
Sous Activer une stratégie, sélectionnez Activé>Créer.

Accédez à nouveau au cluster. Par exemple, en exécutant la commande kubectl get nodes pour afficher les nœuds du cluster :

kubectl get nodes

Suivez les instructions pour vous reconnecter. Un message d’erreur indique que vous êtes bien connecté, mais que votre administrateur exige que l’appareil demandant l’accès soit géré par Microsoft Entra ID afin d’accéder à la ressource. Effectuez les étapes suivantes :

Dans le portail Azure, accédez à Microsoft Entra ID.
Sélectionnez Applications d’entreprise. Sous Activité, sélectionnez Connexions.
Une entrée du haut indique Échoué pour le Status et Succès pour l'accès conditionnel. Sélectionnez l’entrée, puis Accès conditionnel dans Détails. Notez que votre stratégie d’accès conditionnel est indiquée.

Configurer un accès juste-à-temps au cluster avec Microsoft Entra ID

Une autre option pour le contrôle d’accès aux clusters consiste à utiliser Privileged Identity Management (PIM) pour les requêtes juste-à-temps.

Remarque

Microsoft Entra PIM, est une fonctionnalité Microsoft Entra ID P2. Pour obtenir plus d’informations sur les niveaux tarifaires Microsoft Entra ID, consultez le Guide de tarification.

Pour configurer des demandes d’accès juste-à-temps pour votre cluster, procédez comme suit :

En haut du portail Azure, recherchez et sélectionnez Microsoft Entra ID.
Notez l’ID du locataire. Pour le reste de ces instructions, nous faisons référence à cet ID avec <tenant-id>.
Dans le menu Microsoft Entra ID sur le côté gauche, sous Gérer, sélectionnez Groupes>Nouveau groupe.
Vérifiez que Sécurité est sélectionné pour Type de groupe. Entrez un nom de groupe, comme myJITGroup. Sous Rôles Microsoft Entra pouvant être attribués à ce groupe (préversion), sélectionnez Oui. Pour finir, sélectionnez Créer.
Vous serez redirigé vers la page Groupes. Sélectionnez le groupe nouvellement créé et prenez note de l’ID d’objet. Pour le reste de ces instructions, nous faisons référence à cet ID avec <object-id>.
De retour dans le Portail Azure, dans le menu de Activité sur le côté gauche, sélectionnez Accès privilégié (préversion). Sélectionnez ensuite Activer l’accès privilégié.
Sélectionnez Ajouter des affectations pour commencer à accorder l’accès.
Sélectionnez un rôle de Membre, puis choisissez les utilisateurs et les groupes auxquels vous souhaitez accorder l’accès au cluster. Un administrateur de groupe peut modifier ces attributions à tout moment. Quand vous êtes prêt à continuer, choisissez Suivant.
Choisissez un type d’affectation Actif, la durée souhaitée et fournissez une justification. Lorsque vous êtes prêt à continuer, sélectionnez Attribuer. Pour plus d’informations sur les types d’affectations, consultez Attribuer l’éligibilité à l’appartenance ou la propriété d’un groupe d’accès privilégié (préversion) dans Privileged Identity Management.

Après avoir effectué les attributions, vérifiez que l’accès juste-à-temps fonctionne en accédant au cluster. Par exemple, utilisez la commande kubectl get nodes pour afficher les nœuds du cluster :

kubectl get nodes

Notez la configuration requise pour l’authentification et suivez les étapes pour vous authentifier. Si l’authentification réussit, vous devriez voir un résultat semblable à ceci :

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

Étapes suivantes

Connectez-vous en toute sécurité au cluster à l’aide de Connexion au cluster.
Découvrez l’architecture d’Azure RBAC sur Kubernetes avec Arc.

Partager via

Utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure sur des clusters Kubernetes avec Azure Arc

Prérequis

Activer Azure RBAC sur le cluster

Cluster générique dans lequel aucun réconciliateur n’est en cours d’exécution sur la spécification `apiserver`

Cluster créé à l’aide de l’API Cluster

Créer des attributions de rôles pour permettre aux utilisateurs d’accéder au cluster

Rôles intégrés

Rôles personnalisés

Configurer kubectl avec les informations d’identification de l’utilisateur

Utiliser la connexion au cluster

Utiliser un fichier kubeconfig partagé

Envoyez les requêtes au cluster

Utiliser l’accès conditionnel avec Microsoft Entra ID

Configurer un accès juste-à-temps au cluster avec Microsoft Entra ID

Étapes suivantes

Commentaires

Ressources supplémentaires

Partager via

Utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure sur des clusters Kubernetes avec Azure Arc

Prérequis

Activer Azure RBAC sur le cluster

Cluster générique dans lequel aucun réconciliateur n’est en cours d’exécution sur la spécification apiserver

Cluster créé à l’aide de l’API Cluster

Créer des attributions de rôles pour permettre aux utilisateurs d’accéder au cluster

Rôles intégrés

Rôles personnalisés

Configurer kubectl avec les informations d’identification de l’utilisateur

Utiliser la connexion au cluster

Utiliser un fichier kubeconfig partagé

Envoyez les requêtes au cluster

Utiliser l’accès conditionnel avec Microsoft Entra ID

Configurer un accès juste-à-temps au cluster avec Microsoft Entra ID

Étapes suivantes

Commentaires

Ressources supplémentaires

Cluster générique dans lequel aucun réconciliateur n’est en cours d’exécution sur la spécification `apiserver`