Partager via

Obtenir un accès sécurisé pour les ressources Azure dans Azure Kubernetes Service en utilisant Truster Access

  • Article

Cet article vous montre comment obtenir un accès sécurisé pour vos services Azure sur votre serveur d’API Kubernetes dans AKS en utilisant l’accès approuvé.

L’accès approuvé est une fonctionnalité qui offre aux services un accès sécurisé au serveur d’API AKS en utilisant le back‑end Azure sans nécessiter de point de terminaison privé. Au lieu de s’appuyer sur des identités avec des autorisations Microsoft Entra ID, cette fonctionnalité peut utiliser votre identité managée affectée par le système pour s’authentifier sur les services managés et les applications que vous voulez utiliser avec vos clusters AKS.

Remarque

L’API Trusted Access est en disponibilité générale. Nous fournissons une prise en charge de la disponibilité générale (GA) pour Azure CLI, mais elle est toujours en préversion et nécessite l’utilisation de l’extension aks-preview.

Vue d’ensemble de la fonctionnalité Trusted Access

Trusted Access répond aux scénarios suivants :

  • Si une plage d’adresses IP autorisées est définie ou dans un cluster privé, les services Azure peuvent ne pas être en mesure d’accéder au serveur d’API Kubernetes, sauf si vous implémentez un modèle d’accès de point de terminaison privé.
  • Donner à un administrateur de service Azure l’accès à l’API Kubernetes ne suit pas la meilleure pratique d’accès aux privilèges minimum et peut entraîner des élévations de privilèges ou un risque de fuite d’informations d’identification. Par exemple, vous pourriez devoir implémenter des autorisations service-à-service à haut niveau de privilège, et elles ne sont pas idéales dans une revue d’audit.

Vous pouvez utiliser Trusted Access pour donner le consentement explicite à votre identité managée affectée par le système des ressources autorisées d’accéder à vos clusters AKS en utilisant une ressource Azure appelée liaison de rôles. Vos ressources Azure accèdent aux clusters AKS grâce à la passerelle régionale AKS via une authentification par identité managée affectée par le système. Les autorisations Kubernetes appropriées sont affectées via une ressource Azure appelée rôle. En utilisant Trusted Access, vous pouvez accéder aux clusters AKS avec différentes configurations, y compris, mais sans s’y limiter, les clusters privés, les clusters qui ont des comptes locaux désactivés, les clusters Microsoft Entra et les clusters de plage IP autorisée.

Prérequis

Se connecter au cluster

Configurez kubectl pour qu’il se connecte à votre cluster à l’aide de la commande az aks get-credentials.

export RESOURCE_GROUP_NAME="myResourceGroup"
export CLUSTER_NAME="myClusterName"

az aks get-credentials --resource-group ${RESOURCE_GROUP_NAME} --name ${CLUSTER_NAME} --overwrite-existing

Pour vérifier la connexion à votre cluster, exécutez la commande kubectl get.

kubectl get nodes

Sélectionnez les rôles Trusted Access requis

Les rôles que vous sélectionnez dépendent des services Azure pour laquelle vous voulez un accès au cluster AKS. Ces services permettent de créer les rôles et les liaisons de rôles qui établissent la connexion du service Azure à AKS.

Pour trouver les rôles dont vous avez besoin, consultez la documentation du service Azure que vous voulez connecter à AKS. Vous pouvez également utiliser Azure CLI afin de répertorier les rôles disponibles pour le service Azure à l’aide de la commande az aks trustedaccess role list --location <location>.

Créer une liaison de rôles Trusted Access

Après avoir confirmé le rôle à utiliser, utilisez Azure CLI pour créer une liaison de rôles Trusted Access dans le cluster AKS. La liaison de rôles associe le rôle que vous avez choisi au service Azure.

export ROLE_BINDING_NAME="myRoleBindingName"
export SOURCE_RESOURCE_ID="mySourceResourceID"
export ROLE_NAME_1="myRoleName1"
export ROLE_NAME_2="myRoleName2"

az aks trustedaccess rolebinding create --resource-group ${RESOURCE_GROUP_NAME} --cluster-name ${CLUSTER_NAME} --name ${ROLE_BINDING_NAME} --source-resource-id ${SOURCE_RESOURCE_ID} --roles ${ROLE_NAME_1},${ROLE_NAME_2}

Résultats :

{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/${RESOURCE_GROUP_NAME}/providers/Microsoft.ContainerService/managedClusters/${CLUSTER_NAME}/trustedAccessRoleBindings/${ROLE_BINDING_NAME}",
  "name": "${ROLE_BINDING_NAME}",
  "provisioningState": "Succeeded",
  "resourceGroup": "${RESOURCE_GROUP_NAME}",
  "roles": [
    "${ROLE_NAME_1}",
    "${ROLE_NAME_2}"
  ],
  "sourceResourceId": "${SOURCE_RESOURCE_ID}",
  "systemData": null,
  "type": "Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings"
}

Mettre à jour une liaison de rôles Trusted Access existante

Dans les cas d’une liaison de rôles existante avec un service source associé, vous pouvez la mettre à jour avec de nouveaux rôles à l’aide de la commande az aks trustedaccess rolebinding update --resource-group $RESOURCE_GROUP_NAME --cluster-name $CLUSTER_NAME --name $ROLE_BINDING_NAME --roles $ROLE_NAME_3,$ROLE_NAME_4. Cette commande met à jour la liaison avec les nouveaux rôles que vous spécifiez.

Remarque

Le gestionnaire de modules complémentaires met à jour les clusters toutes les cinq minutes, de sorte que la nouvelle liaison de rôles peut mettre jusqu’à cinq minutes pour prendre effet. Avant que la nouvelle liaison de rôles ne prenne effet, la liaison de rôles existante fonctionne toujours.

Vous pouvez utiliser la commande az aks trusted access rolebinding list pour vérifier la liaison de rôles actuelle.

Afficher une liaison de rôles Trusted Access

Afficher une liaison de rôle spécifique avec accès approuvé en utilisant la commande az aks trustedaccess rolebinding show --name $ROLE_BINDING_NAME --resource-group $RESOURCE_GROUP_NAME --cluster-name $CLUSTER_NAME.

Lister toutes les liaisons de rôles Trusted Access pour un cluster

Lister toutes les liaisons de rôles avec accès approuvé pour un cluster en utilisant la commande az aks trustedaccess rolebinding list --resource-group $RESOURCE_GROUP_NAME --cluster-name $CLUSTER_NAME.

Contenu connexe