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

  • Article

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.

Important

Les fonctionnalités d’évaluation de Kubernetes avec Azure Arc sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions de Kubernetes avec Azure Arc sont, dans la mesure du possible, partiellement couvertes par le service clientèle.

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 :

Remarque

Vous ne pouvez pas configurer cette fonctionnalité pour Red Hat OpenShift ou pour les offres Kubernetes managées de fournisseurs cloud comme Elastic Kubernetes Service ou Google Kubernetes Engine où l’utilisateur n’a pas d’accès au serveur API du cluster. 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.

Configurer des applications Microsoft Entra

Créer une application serveur

  1. Créez une nouvelle application Microsoft Entra et récupérez sa valeur appId. Cette valeur est utilisée dans les étapes ultérieures comme 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

  2. Pour accorder des autorisations d’API « Se connecter et lire le profil utilisateur » à l’application serveur, copiez ce JSON et enregistrez-le dans un fichier appelé 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"
        }
    ]
}

  3. Mettez à jour les revendications d’appartenance au groupe de l’application. Exécutez les commandes dans le même répertoire que le fichier oauth2-permissions.json. RBAC pour Kubernetes avec Azure Arc exige que signInAudience soit défini sur AzureADMyOrg :

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

  4. Créez un principal de service et récupérez sa valeur de champ password. Cette valeur est requise ultérieurement en tant que serverApplicationSecret quand vous activez cette fonctionnalité sur le cluster. Par défaut, ce secret est valide pendant un an et devra faire l’objet d’une rotation après ce délai. Pour définir une durée d’expiration personnalisée, utilisez 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)

  5. Accordez des autorisations d’API « connexion et lecture du profil utilisateur » à l’application en utilisant 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

    Remarque

    Un administrateur d’applications Azure doit exécuter cette étape.

    Pour l’utilisation de cette fonctionnalité en production, nous recommandons de créer une application serveur différente pour chaque cluster.

Créer une application cliente

  1. Créez une nouvelle application Microsoft Entra et récupérez sa valeur appId. Cette valeur est utilisée dans les étapes ultérieures comme 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

  2. Créez un principal de service pour l’application cliente :

    az ad sp create --id "${CLIENT_APP_ID}"

  3. Obtenez la valeur oAuthPermissionId pour l’application serveur :

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

  4. Accordez les autorisations nécessaires à l’application cliente. RBAC pour Kubernetes avec Azure Arc exige que signInAudience soit défini sur AzureADMyOrg :

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

Créez une attribution de rôle pour l’application serveur

L’application serveur a besoin des autorisations Microsoft.Authorization/*/readpour pouvoir confirmer que l’utilisateur qui effectue la demande est autorisé sur les objets Kubernetes inclus dans la demande.

  1. Créez un fichier nommé accessCheck.json avec les éléments suivants :

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

    Remplacez <subscription-id> par l’ID d’abonnement réel.

  2. Exécutez la commande suivante pour créer le nouveau rôle personnalisé :

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

  3. Créez une attribution de rôle sur l’application serveur en tant que assignee à l’aide du rôle que vous avez créé :

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

Activer Azure RBAC sur le cluster

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 --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

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

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

    Si votre kube-apiserver est un Pod statique:

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

    2. Ouvrez le manifeste apiserver en mode édition :

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

    3. Utilisez la spécification suivante sous volumes :

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

    4. 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 :

    1. Ouvrez le manifeste apiserver en mode édition :

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

    2. Utilisez la spécification suivante sous volumes :

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

    3. Utilisez la spécification suivante sous volumeMounts :

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

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

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

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

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

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

  3. Appliquez ce manifeste :

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

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

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

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

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

    4. 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>"
    ]
}

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

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

  1. Exécutez la commande suivante pour définir les informations d’identification de l’utilisateur :

    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>

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

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

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

  2. Convertissez 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

Envoyez les requêtes au cluster

  1. Exécutez une commande kubectl. Par exemple :

    • kubectl get nodes
    • kubectl get pods

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

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

  4. Entrez le nom d’utilisateur (testuser@mytenant.onmicrosoft.com) et le mot de passe associé.

  5. 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 :

  1. En haut du portail Azure, recherchez et sélectionnez Microsoft Entra ID.

  2. Dans le menu Microsoft Entra ID sur le côté gauche, sélectionnez Applications d’entreprise.

  3. Dans le menu Applications d’entreprise sur le côté gauche, sélectionnez Accès conditionnel.

  4. Sur le menu Accès conditionnel sur le côté gauche, sélectionnez Stratégies>Nouvelle stratégie.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Entrez le nom de la stratégie, par exemple arc-k8s-policy.

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

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

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

    Screenshot showing how to select a server application in the Azure portal.

  8. Sous Contrôles d’accès, sélectionnez Accorder. Sélectionnez Accorder l’accès>Exiger que l’appareil soit marqué comme conforme.

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. Sous Activer une stratégie, sélectionnez Activé>Créer.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

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 :

  1. Dans le portail Azure, accédez à Microsoft Entra ID.

  2. Sélectionnez Applications d’entreprise. Sous Activité, sélectionnez Connexions.

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

    Screenshot showing a failed sign-in entry in the Azure portal.

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 :

  1. En haut du portail Azure, recherchez et sélectionnez Microsoft Entra ID.

  2. Notez l’ID du locataire. Pour le reste de ces instructions, nous faisons référence à cet ID avec <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. Dans le menu Microsoft Entra ID sur le côté gauche, sous Gérer, sélectionnez Groupes>Nouveau groupe.

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

    Screenshot showing details for the new group in the Azure portal.

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

    Screenshot showing the object ID for the new group in the Azure portal.

  6. 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é.

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. Sélectionnez Ajouter des affectations pour commencer à accorder l’accès.

    Screenshot showing how to add active assignments in the Azure portal.

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

    Screenshot showing how to add assignments in the Azure portal.

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

    Screenshot showing assignment properties in the Azure portal.

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

Actualiser le secret de l’application serveur

Si le secret du principal de service de l’application serveur a expiré, vous devez le faire tourner.

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

Mettez à jour le secret sur le cluster. Incluez les paramètres facultatifs que vous avez configurés lorsque la commande a été exécutée la première fois.

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

Étapes suivantes