Configurer des liaisons d’identité sur Azure Kubernetes Service (AKS) (préversion)

Configurez des liaisons d’identité sur vos clusters Azure Kubernetes Service (AKS) pour mapper une identité managée affectée par l’utilisateur (UAMI) sur plusieurs clusters tout en utilisant un seul FIC (Federated Identity Credential). Cette configuration vous aide à mettre à l’échelle l’authentification Microsoft Entra pour les charges de travail sans atteindre les limites FIC.

Prerequisites

Installer ou mettre à jour l’extension aks-preview

  • Installez ou mettez à jour l’extension Azure CLI aks-preview vers la dernière version en utilisant les commandes az extension add ou az extension update.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview

Activer le drapeau de fonctionnalité IdentityBindingPreview

  1. Inscrivez l'indicateur de fonctionnalité IdentityBindingPreview sur votre abonnement Azure à l’aide de la commande az feature register.

    az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview

    L’inscription des fonctionnalités peut prendre jusqu’à 15 minutes.

  2. Attendez que la fonctionnalité termine l’inscription à l’aide de la commande az feature show.

    az feature show --namespace Microsoft.ContainerService --name IdentityBindingPreview

  3. Une fois que la fonctionnalité s’affiche Registered, actualisez l’inscription du fournisseur à l’aide de la az provider register commande.

    az provider register --namespace Microsoft.ContainerService

Limites

Créer des ressources de test

  1. Créez un groupe de ressources Azure à l’aide de la commande az group create.

    export RESOURCE_GROUP="ib-test"
export LOCATION="westus2"

az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Créez un cluster AKS avec l’identité de charge de travail et l’émetteur OIDC activés à l’aide de la commande az aks create, avec les indicateurs --enable-workload-identity et --enable-oidc-issuer.

    export CLUSTER_NAME="ib-test-cluster"

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --location $LOCATION --no-ssh-key --enable-workload-identity --enable-oidc-issuer

  3. Créez une identité managée affectée par l’utilisateur (UAMI) à l’aide de la az identity create commande.

    export MI_NAME="ib-test-mi"
az identity create --resource-group $RESOURCE_GROUP --name $MI_NAME

Vérifiez la version du webhook d’identité de charge de travail.

  • La liaison d’identité requiert la version préliminaire du webhook d’identité de charge de travail. Vérifiez la version du webhook installée à l’aide de la commande suivante kubectl get pods :

    kubectl -n kube-system get pods -l azure-workload-identity.io/system=true -o yaml | grep v1.6.0

    La sortie doit s’afficher v1.6.0-alpha.1 dans la balise d’image, ce qui confirme que la version correcte est installée.

Obtenir les ID UAMI

  • Obtenez les ID de ressource, de principal, de client et de locataire de l’UAMI et définissez-les en tant que variables d’environnement à l’aide des commandes suivantes az identity show :

    export MI_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query id --output tsv)
export MI_PRINCIPAL_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query principalId --output tsv)
export MI_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query clientId --output tsv)
export MI_TENANT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query tenantId --output tsv)

Créer une liaison d’identité

  • Associez l’UAMI au cluster AKS via une liaison d’identité à l’aide de la commande az aks identity-binding create.

    az aks identity-binding create --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib" --managed-identity-resource-id $MI_RESOURCE_ID

    Note

    Lors de la création d’une liaison d’identité, AKS génère automatiquement un certificat d’identité fédéré (FIC) nommé aks-identity-binding sous l’UAMI. Ce certificat est administré par AKS. Veuillez ne pas le modifier ni le supprimer tant que des liaisons d’identité sont en cours d’utilisation. Le FIC créé pour les liens d’identité est partagé entre tous les liens d’identité faisant référence au même UAMI.

Obtenir l’URL de l’émetteur OIDC pour l’UAMI

  • Obtenez l’URL de l’émetteur OIDC associée à l’UAMI en inspectant la liaison d’identité à l’aide de la commande az aks identity-binding show.

    az aks identity-binding show --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib"

    Exemple de sortie condensé :

    {
  "oidcIssuer": {
    "oidcIssuerUrl": "https://ib.oic.prod-aks.azure.com/<MI-tenant-id>/<MI-client-id>"
  }
}

Se connecter au cluster AKS

  1. Obtenez les informations d’identification du cluster AKS à l’aide de la az aks get-credentials commande et enregistrez-les dans un fichier kubeconfig distinct :

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME -a -f "${CLUSTER_NAME}.kubeconfig"

  2. Définissez la variable d’environnement pour qu’elle KUBECONFIG pointe vers le nouveau fichier kubeconfig :

    export KUBECONFIG="$(pwd)/${CLUSTER_NAME}.kubeconfig"

Autoriser les espaces de noms et les comptes de service

  • Configurez le contrôle d’accès en fonction du rôle (RBAC) pour accorder aux sujets spécifiques l’autorisation d’utiliser l’identité managée via la liaison d’identité en appliquant le manifeste suivant à l’aide de la commande suivante kubectl apply .

    Note

    L’exemple suivant fait explicitement référence au compte de service demo dans l’espace de noms demo. Faire explicitement référence à un compte de service spécifique est une option, mais il est également possible de faire référence à une collection de comptes de service sous subjects. Pour plus d’informations, consultez référence à des sujets dans la documentation Kubernetes.

    kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo
  namespace: demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-mi-${MI_CLIENT_ID}
rules:
  - verbs: ["use-managed-identity"]
    apiGroups: ["cid.wi.aks.azure.com"]
    resources: ["${MI_CLIENT_ID}"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: use-mi-${MI_CLIENT_ID}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-mi-${MI_CLIENT_ID}
subjects:
  - kind: ServiceAccount
    name: demo
    namespace: demo
EOF

Créer un coffre de clés avec la protection contre la purge et l’autorisation Azure RBAC

  • Créez un Key Vault avec la protection contre la purge et l’autorisation Azure RBAC activées à l’aide de la commande az keyvault create, avec les indicateurs --enable-purge-protection et --enable-rbac-authorization. Vous pouvez également utiliser un Key Vault existant s’il est configuré à la fois avec la protection contre la purge et l’autorisation Azure RBAC.

    export KEY_VAULT_NAME="ib-test"

az keyvault create \
    --name $KEY_VAULT_NAME \
    --resource-group $RESOURCE_GROUP \
    --location $LOCATION \
    --enable-purge-protection \
    --enable-rbac-authorization

Obtenir l’ID de ressource et l’URL du coffre de clés

  1. Obtenez l’ID de ressource du coffre de clés à l’aide de la commande et définissez-la az keyvault show en tant que variable d’environnement :

    export KEY_VAULT_RESOURCE_ID=$(az keyvault show --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query id \
    --output tsv)

  2. Obtenez l’URL du coffre de clés à l’aide de la commande et définissez-la az keyvault show en tant que variable d’environnement :

    export KEYVAULT_URL="$(az keyvault show \
    --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query properties.vaultUri \
    --output tsv)"

Configurer l’accès au coffre de clés et créer un secret

Les étapes suivantes montrent comment accéder aux secrets, clés ou certificats dans Azure Key Vault à partir du pod. Les exemples de cette section configurent l’accès aux secrets dans le coffre de clés pour l’identité de charge de travail, mais vous pouvez effectuer des étapes similaires pour configurer l’accès aux clés ou aux certificats.

L’exemple suivant illustre l’utilisation du modèle d’autorisation Azure RBAC pour accorder au pod l’accès au Key Vault. Pour plus d’informations sur le modèle d’autorisation RBAC Azure pour Azure Key Vault, consultez Accorder l’autorisation aux applications d’accéder à Azure Key Vault à l’aide d’Azure RBAC.

  1. Obtenez l’ID d’objet de l’utilisateur connecté à l’aide de la commande et définissez-la az ad signed-in-user show en tant que variable d’environnement :

    export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id --output tsv)

  2. Attribuez-vous le rôle Azure RBAC Key Vault Secrets Officer sur le Key Vault à l’aide de la commande az role assignment create.

    az role assignment create --assignee $CALLER_OBJECT_ID \
    --role "Key Vault Secrets Officer" \
    --scope $KEY_VAULT_RESOURCE_ID

  3. Créez un secret dans le coffre-fort de clés à l’aide de la commande az keyvault secret set.

    export KEY_VAULT_SECRET_NAME="my-secret"

az keyvault secret set \
    --vault-name $KEY_VAULT_NAME \
    --name $KEY_VAULT_SECRET_NAME \
    --value "Hello\!"

  4. Attribuez le rôle Utilisateur des secrets Key Vault à l’UAMI à l’aide de la commande az role assignment create.

    az role assignment create \
    --assignee-object-id $MI_PRINCIPAL_ID \
    --role "Key Vault Secrets User" \
    --scope $KEY_VAULT_RESOURCE_ID \
    --assignee-principal-type ServicePrincipal

Annoter le compte de service

  1. Annotez le compte de service avec l’ID de locataire de l’identité gérée à l’aide de la commande kubectl annotate.

    kubectl annotate sa demo -n demo azure.workload.identity/tenant-id=$MI_TENANT_ID

  2. Annotez le compte de service avec l’ID client d’identité managée en utilisant la commande kubectl annotate.

    kubectl annotate sa demo -n demo azure.workload.identity/client-id=$MI_CLIENT_ID

Déployer un exemple d’application

  • Déployez l’exemple de pod qui utilise la liaison d’identité pour obtenir un jeton d’accès pour l’identité managée afin d’accéder à Azure Key Vault à l’aide de la commande suivante kubectl apply :

    kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: demo
  labels:
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/use-identity-binding: "true"
spec:
  serviceAccount: demo
  containers:
    - name: azure-sdk
      # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go
      image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64
      env:
        - name: KEYVAULT_URL
          value: ${KEYVAULT_URL}
        - name: SECRET_NAME
          value: ${KEY_VAULT_SECRET_NAME}
  restartPolicy: Never
EOF

Vérifier l’accès au coffre de clés à partir d’un exemple d’application

  1. Décrivez le pod et vérifiez la présence des variables d’environnement ainsi que des montages de volume de jetons projetés à l’aide de la commande kubectl describe pod.

    kubectl describe pod demo -n demo

    La sortie attendue doit contenir des valeurs pour AZURE_CLIENT_ID, , AZURE_TENANT_IDAZURE_FEDERATED_TOKEN_FILE, AZURE_AUTHORITY_HOST, AZURE_KUBERNETES_TOKEN_PROXY. AZURE_KUBERNETES_SNI_NAME et AZURE_KUBERNETES_CA_FILE.

  2. Vérifiez que le pod peut obtenir un jeton et accéder à la ressource à l’aide de la kubectl logs commande.

    kubectl logs demo -n demo

    Si elle réussit, la sortie doit être similaire à l’exemple suivant :

    I1107 20:03:42.865180       1 main.go:77] "successfully got secret" secret="Hello!"

Faites évoluer les liaisons d’identité sur plusieurs clusters.

Les liaisons d’identité permettent de mapper plusieurs clusters AKS au même UAMI tout en utilisant un seul FIC. Pour mettre à l’échelle les liaisons d’identité entre plusieurs clusters, vous pouvez répéter les étapes de la création d’une liaison d’identité via la vérification de l’accès au coffre de clés à partir d’un exemple d’application pour chaque cluster supplémentaire que vous souhaitez mapper au même UAMI (création d’une liaison d’identité par cluster).

Nettoyer les ressources

Si vous n’avez plus besoin des ressources que vous avez créées dans cet article, vous pouvez les nettoyer pour éviter les coûts futurs.

  1. Supprimez le pod à l’aide de la kubectl delete pod commande.

    kubectl delete pod demo -n demo

  2. Supprimez l’espace de noms à l’aide de la kubectl delete ns commande.

    kubectl delete ns demo

  3. Supprimez le groupe de ressources et toutes les ressources associées à l’aide de la az group delete commande.

    az group delete --name $RESOURCE_GROUP --yes --no-wait

Contenu connexe

  • Last updated on