Déployer un cluster AKS avec des conteneurs confidentiels et une stratégie par défaut

Article
08/02/2024

Dans cet article, vous utilisez Azure CLI pour déployer un cluster Azure Kubernetes Service (AKS) et configurer des conteneurs confidentiels (préversion) avec une stratégie de sécurité par défaut. Vous déployez ensuite une application en tant que conteneur confidentiel. Pour en savoir plus, lisez la vue d'ensemble des conteneurs confidentiels AKS.

En général, bien démarrer avec les conteneurs confidentiels AKS implique les étapes suivantes.

Déployer ou mettre à niveau un cluster AKS à l'aide d'Azure CLI
Ajouter une annotation à votre manifeste YAML de pod pour marquer le pod comme étant exécuté en tant que conteneur confidentiel
Ajouter une stratégie de sécurité au manifeste YAML de votre pod
Activer l'application de la stratégie de sécurité
Déployer votre application dans un calcul confidentiel

Prérequis

Azure CLI version 2.44.1 ou ultérieure. Exécutez az --version pour rechercher la version, puis exécutez az upgrade pour mettre à niveau la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
L'extension Azure CLI aks-preview version 0.5.169 ou ultérieure.
L’extension confcom pour les conteneurs confidentiels Azure CLI version 0.3.3 ou ultérieure. confcom est nécessaire pour générer une stratégie de sécurité.
Enregistrer la fonctionnalité Preview dans votre abonnement Azure.
AKS prend en charge les conteneurs confidentiels (préversion) à partir de la version 1.25.0.
Une identité de charge de travail et des informations d'identification d'identité fédérée. Les informations d'identification de l'identité de charge de travail permettent aux applications Kubernetes d'accéder en toute sécurité aux ressources Azure avec Microsoft Entra ID basé sur des comptes de service annotés. Si vous n'êtes pas familiarisé avec l'ID de charge de travail Microsoft Entra, reportez-vous à la vue d'ensemble de l'ID de charge de travail Microsoft Entra et révisez le fonctionnement de l'identité de charge de travail avec AKS.
L’identité que vous utilisez pour créer votre cluster dispose des autorisations minimales appropriées. Pour plus d’informations concernant l’accès et l’identité pour AKS, consultez Options d’accès et d’identité pour Kubernetes Azure Service (AKS).
Pour gérer un cluster Kubernetes, utilisez le client de ligne de commande de Kubernetes kubectl. Azure Cloud Shell comprend kubectl. Vous pouvez installer kubectl en local à l’aide de la commande az aks install-cli.
Les conteneurs confidentiels sur AKS fournissent un conteneur de sidecar open source pour l'attestation et la mise en production de clé sécurisée. Le sidecar s'intègre à un service de gestion des clés (KMS), comme Azure Key Vault, pour mettre en production une clé dans le groupe de conteneurs une fois la validation terminée. Le déploiement d'un HSM managé Azure Key Vault (module de sécurité matérielle) est facultatif. Il est toutefois recommandé pour prendre en charge l'intégrité et l'attestation au niveau du conteneur. Reportez-vous à Approvisionner et activer un HSM managé pour déployer un HSM managé.

Installer l’extension Azure CLI aks-preview

Important

Les fonctionnalités d’évaluation AKS 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 AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Exécutez la commande suivante pour installer l’extension aks-preview :

az extension add --name aks-preview

Exécutez la commande suivante pour effectuer la mise à jour vers la dernière version de l’extension publiée :

az extension update --name aks-preview

Installer l'extension Azure CLI confcom

Pour installer l'extension confcom, exécutez la commande suivante :

az extension add --name confcom

Exécutez la commande suivante pour effectuer la mise à jour vers la dernière version de l’extension publiée :

az extension update --name confcom

Enregistrer l'indicateur de fonctionnalité KataCcIsolationPreview

Inscrivez l’indicateur de fonctionnalité KataCcIsolationPreview à l’aide de la commande az feature register, comme indiqué dans l’exemple suivant :

az feature register --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit). Vérifiez l’état de l’inscription à l’aide de la commande az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Une fois que l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register :

az provider register --namespace "Microsoft.ContainerService"

Déployez un nouveau cluster.

Créez un cluster AKS avec la commande az aks create, tout en spécifiant les paramètres suivants :
- --os-sku : AzureLinux. Seule la référence os-sku Azure Linux prend en charge cette fonctionnalité dans cette préversion.
- --node-vm-size : toute taille de machine virtuelle Azure de génération 2 prenant en charge la virtualisation imbriquée fonctionne. Par exemple, Standard_DC8as_cc_v5 machines virtuelles.
- --enable-workload-identity : permet de créer un ID de charge de travail Microsoft Entra permettant aux pods d'utiliser une identité Kubernetes.
- --enable-oidc-issuer : active l'émetteur OpenID Connect (OIDC). Cette option permet à une plateforme de gestion des identités et des accès de Microsoft Entra ID ou d'un autre fournisseur de cloud de découvrir les clés de signature publiques du serveur API.
L'exemple suivant met à jour le cluster nommé myAKSCluster et crée un pool de nœuds système unique dans myResourceGroup :
```
az aks create --resource-group myResourceGroup --name myAKSCluster --kubernetes-version <1.25.0 and above> --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --node-count 1 --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys
```
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster. Le cluster créé à l’étape précédente dispose d’un pool de nœuds unique. À l'étape suivante, nous ajoutons un deuxième pool de nœuds au cluster.
Lorsque le cluster est prêt, obtenez les informations d'identification du cluster à l'aide de la commande az aks get-credentials.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
Ajoutez un pool de nœuds utilisateur à myAKSCluster avec deux nœuds dans nodepool2 dans myResourceGroup à l'aide de la commande az aks nodepool add. Spécifiez les paramètres suivants :
- --workload-runtime : Spécifiez KataCcIsolation pour activer la fonctionnalité Conteneurs confidentiels sur le pool de nœuds. Avec ce paramètre, les autres paramètres doivent satisfaire aux exigences suivantes. Autrement, la commande échoue et rapporte un problème avec le(s) paramètre(s) correspondant(s).
- --os-sku : AzureLinux. Seule la référence os-sku Azure Linux prend en charge cette fonctionnalité dans cette préversion.
- --node-vm-size : toute taille de machine virtuelle Azure de génération 2 prenant en charge la virtualisation imbriquée fonctionne. Par exemple, Standard_DC8as_cc_v5 machines virtuelles.
```
az aks nodepool add --resource-group myResourceGroup --name nodepool2 --cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation
```

Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.

Déployer sur un cluster existant

Pour utiliser cette fonctionnalité avec un cluster AKS existant, les conditions suivantes doivent être satisfaites :

Suivez les étapes pour enregistrer l'indicateur de fonctionnalité KataCcIsolationPreview.
Vérifiez que le cluster exécute Kubernetes version 1.25.0 ou ultérieure.
Activer l'identité de charge de travail sur le cluster si ce n'est pas déjà le cas.

Utilisez la commande suivante pour activer les conteneurs confidentiels (préversion) en créant un pool de nœuds pour l'héberger.

Ajoutez un pool de nœuds à votre cluster AKS avec la commande az aks nodepool add. Spécifiez les paramètres suivants :
- --resource-group : saisissez le nom d’un groupe de ressources existant dans lequel le cluster AKS sera créé.
- --cluster-name : saisissez un nom unique pour le cluster AKS, comme myAKSCluster.
- --name : saisissez un nom unique pour votre pool de nœuds de clusters, par exemple nodepool2.
- --workload-runtime : spécifiez KataCcIsolation pour activer la fonctionnalité sur le pool de nœuds. Avec ce paramètre --workload-runtime, les autres paramètres doivent satisfaire aux exigences suivantes. Autrement, la commande échoue et rapporte un problème avec le(s) paramètre(s) correspondant(s).
- --os-sku : AzureLinux. Seule la référence os-sku Azure Linux prend en charge cette fonctionnalité dans cette préversion.
- --node-vm-size : toute taille de machine virtuelle Azure de génération 2 prenant en charge la virtualisation imbriquée fonctionne. Par exemple, Standard_DC8as_cc_v5 machines virtuelles.
L'exemple suivant ajoute un pool de nœuds utilisateur à myAKSCluster avec deux nœuds dans nodepool2 dans myResourceGroup :
```
az aks nodepool add --resource-group myResourceGroup --name nodepool2 –-cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation
```
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Exécutez la commande az aks update pour activer les conteneurs confidentiels (préversion) sur le cluster.
```
az aks update --name myAKSCluster --resource-group myResourceGroup
```
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.
Lorsque le cluster est prêt, obtenez les informations d'identification du cluster à l'aide de la commande az aks get-credentials.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

Configurer le conteneur

Avant de configurer l'accès à Azure Key Vault et au secret, et de déployer une application en tant que conteneur confidentiel, vous devez terminer la configuration de l'identité de la charge de travail.

Pour configurer l'identité de la charge de travail, exécutez les étapes suivantes décrites dans l'article Déployer et configurer l'identité de la charge de travail :

Obtenir l’URL de l’émetteur OIDC
Créer une identité managée
Créer un compte de service Kubernetes
Établir des informations d’identification d’identité fédérée

Important

Vous devez définir les variables d’environnement de la section Exporter les variables d’environnement dans l’article Déployer et configurer l’identité de charge de travail pour continuer à suivre ce tutoriel. N’oubliez pas de définir la variable SERVICE_ACCOUNT_NAMESPACE sur kafka et d’exécuter la commande kubectl create namespace kafka avant de configurer l’identité de charge de travail.

Déployer une application approuvée avec kata-cc et un conteneur d'attestation

Les étapes suivantes configurent le chiffrement de bout en bout des messages Kafka à l'aide de clés de chiffrement gérées par Azure Managed Hardware Security Modules (mHSM). La clé n'est mise en production que lorsque le consommateur Kafka s'exécute dans un conteneur confidentiel avec un conteneur d'approvisionnement de secret d'attestation Azure injecté dans le pod.

Cette configuration est basée sur les quatre composants suivants :

cluster Kafka : Un simple cluster Kafka déployé dans l'espace de noms Kafka sur le cluster.
Producteur Kafka : un producteur Kafka s'exécutant en tant que pod Kubernetes vanille qui envoie des messages chiffrés configurés par l'utilisateur à l'aide d'une clé publique vers un sujet Kafka.
Consommateur Kafka : un pod consommateur Kafka fonctionnant avec le runtime kata-cc, équipé d'un conteneur de mise en production de clés sécurisées pour récupérer la clé privée afin de déchiffrer les messages Kafka et de les restituer à l'interface utilisateur Web.

Pour cette préversion, nous vous recommandons de créer ou d'utiliser une ressource de niveau Premium Azure Key Vault existante pour prendre en charge le stockage de clés dans un module de sécurité matériel (HSM). Nous vous déconseillons d'utiliser votre coffre de clés de production. Si vous n'avez pas Azure Key Vault, reportez-vous à Créer un coffre de clés à l'aide d'Azure CLI.

Accordez à l'identité managée que vous avez créée précédemment, et à votre compte, l'accès au coffre de clés. Attribuez les deux identités à l'agent de chiffrement Key Vault et aux rôles RBAC Azure de l'utilisateur de chiffrement Key Vault.
Remarque
- L'identité managée est la valeur que vous affectez à la variable USER_ASSIGNED_IDENTITY_NAME.
- Pour ajouter des attributions de rôle, vous devez avoir les autorisations Microsoft.Authorization/roleAssignments/write et Microsoft.Authorization/roleAssignments/delete, comme Administrateur de l’accès aux données Key Vault, Administrateur de l’accès utilisateur ou Propriétaire.
- Vous devez utiliser la référence SKU Key Vault Premium pour prendre en charge les clés protégées par HSM.
Exécutez la commande suivante pour définir l'étendue :
```
AKV_SCOPE=$(az keyvault show --name <AZURE_AKV_RESOURCE_NAME> --query id --output tsv)
```
exécutez la commande suivante pour attribuer le rôle Agent de chiffrement Key Vault.
```
az role assignment create --role "Key Vault Crypto Officer" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE
```
Exécutez la commande suivante pour attribuer le rôle Utilisateur de chiffrement Key Vault.
```
az role assignment create --role "Key Vault Crypto User" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE
```
Installez le cluster kafka dans l’espace de noms kafka en exécutant la commande suivante :
```
kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka
```

exécutez la commande suivante pour appliquer le fichier CR du cluster kafka.

kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafka

Préparez la clé de chiffrement/déchiffrement RSA en utilisant le script bash pour la charge de travail à partir de GitHub. Enregistrez le fichier sous le nom setup-key.sh.
Définissez la variable d’environnement MAA_ENDPOINT avec le nom de domaine complet de l’URI Attest en exécutant la commande suivante.
```
export MAA_ENDPOINT="$(az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9-)"
```
Vérifiez si le nom de domaine complet de l’URI d’attestation est au format correct (le MAA_ENDPOINT ne doit pas inclure le préfixe « https:// ») :
```
echo $MAA_ENDPOINT
```
Remarque

Pour configurer Microsoft Azure Attestation, consultez Démarrage rapide : configurer Azure Attestation avec Azure CLI.

Copiez le manifeste YAML suivant et enregistrez-le sous consumer.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: kafka-golang-consumer
  namespace: kafka
  labels:
    azure.workload.identity/use: "true"
    app.kubernetes.io/name: kafka-golang-consumer
spec:
  serviceAccountName: workload-identity-sa
  runtimeClassName: kata-cc-isolation
  containers:
    - image: "mcr.microsoft.com/aci/skr:2.7"
      imagePullPolicy: Always
      name: skr
      env:
        - name: SkrSideCarArgs
          value: ewogICAgImNlcnRjYWNoZSI6IHsKCQkiZW5kcG9pbnRfdHlwZSI6ICJMb2NhbFRISU0iLAoJCSJlbmRwb2ludCI6ICIxNjkuMjU0LjE2OS4yNTQvbWV0YWRhdGEvVEhJTS9hbWQvY2VydGlmaWNhdGlvbiIKCX0gIAp9
      command:
        - /bin/skr
      volumeMounts:
        - mountPath: /opt/confidential-containers/share/kata-containers/reference-info-base64
          name: endor-loc
    - image: "mcr.microsoft.com/acc/samples/kafka/consumer:1.0"
      imagePullPolicy: Always
      name: kafka-golang-consumer
      env:
        - name: SkrClientKID
          value: kafka-encryption-demo
        - name: SkrClientMAAEndpoint
          value: sharedeus2.eus2.test.attest.azure.net
        - name: SkrClientAKVEndpoint
          value: "myKeyVault.vault.azure.net"
        - name: TOPIC
          value: kafka-demo-topic
      command:
        - /consume
      ports:
        - containerPort: 3333
          name: kafka-consumer
      resources:
        limits:
          memory: 1Gi
          cpu: 200m
  volumes:
    - name: endor-loc
      hostPath:
        path: /opt/confidential-containers/share/kata-containers/reference-info-base64
---
apiVersion: v1
kind: Service
metadata:
  name: consumer
  namespace: kafka
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: kafka-golang-consumer
  ports:
    - protocol: TCP
      port: 80
      targetPort: kafka-consumer

Remarque

Mettez à jour la valeur de la variable d'environnement pod SkrClientAKVEndpoint pour qu'elle corresponde à l'URL de votre Azure Key Vault, à l'exclusion de la valeur de protocole https://. La valeur d'espace réservé de valeur actuelle est myKeyVault.vault.azure.net. Mettez à jour la valeur de la variable d’environnement de pod SkrClientMAAEndpoint avec la valeur de MAA_ENDPOINT. Vous pouvez trouver la valeur MAA_ENDPOINT en exécutant de la commande echo $MAA_ENDPOINT ou de la commande az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9-.

Générer la stratégie de sécurité pour le manifeste YAML du consommateur Kafka et obtenir le hachage de la stratégie de sécurité stockée dans la variable WORKLOAD_MEASUREMENT en exécutant la commande suivante :
```
export WORKLOAD_MEASUREMENT=$(az confcom katapolicygen -y consumer.yaml --print-policy | base64 -d | sha256sum | cut -d' ' -f1)
```
Pour générer une paire de clés asymétriques RSA (clés publique et privée), exécutez le script setup-key.sh à l'aide de la commande suivante. La valeur <Azure Key Vault URL> doit être <your-unique-keyvault-name>.vault.azure.net
```
export MANAGED_IDENTITY=${USER_ASSIGNED_CLIENT_ID}
bash setup-key.sh "kafka-encryption-demo" <Azure Key Vault URL>
```
Remarque
- La variable d’environnement MANAGED_IDENTITY est requise par le script bash setup-key.sh.
- La clé publique est enregistrée comme kafka-encryption-demo-pub.pem après l’exécution du script bash.
Important

Si vous recevez l’erreur ForbiddenByRbac, il se peut que vous deviez attendre jusqu’à 24 heures, car les services principaux pour les identités managées conservent un cache par URI de ressource pendant jusqu’à 24 heures. Voir aussi : Résoudre les problèmes liés au contrôle d’accès en fonction du rôle (RBAC) d’Azure .
Pour vérifier que les clés ont bien été téléchargées dans le coffre de clés, exécutez les commandes suivantes :
```
az account set --subscription <Subscription ID>
az keyvault key list --vault-name <KeyVault Name> -o table
```

Copiez le manifeste YAML suivant et enregistrez-le sous producer.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: kafka-producer
  namespace: kafka
spec:
  containers:
    - image: "mcr.microsoft.com/acc/samples/kafka/producer:1.0"
      name: kafka-producer
      command:
        - /produce
      env:
        - name: TOPIC
          value: kafka-demo-topic
        - name: MSG
          value: "Azure Confidential Computing"
        - name: PUBKEY
          value: |-
            -----BEGIN PUBLIC KEY-----
            MIIBojAN***AE=
            -----END PUBLIC KEY-----
      resources:
        limits:
          memory: 1Gi
          cpu: 200m

Remarque

Mettez à jour la valeur qui commence par -----BEGIN PUBLIC KEY----- et se termine par -----END PUBLIC KEY----- des chaînes avec le contenu kafka-encryption-demo-pub.pem à partir duquel a été créé à l’étape précédente.

déployez les manifestes YAML consumer et producer en utilisant les fichiers que vous avez sauvegardés précédemment.
```
kubectl apply -f consumer.yaml
```
```
kubectl apply -f producer.yaml
```
Obtenez l'adresse IP du service web à l'aide de la commande suivante :
```
kubectl get svc consumer -n kafka
```
Copiez et collez l'adresse IP externe du service consommateur dans votre navigateur et vérifiez le message déchiffré.

L’exemple suivant ressemble à la sortie de la commande :
```
Welcome to Confidential Containers on AKS!
Encrypted Kafka Message:
Msg 1: Azure Confidential Computing
```
Essayez en outre d'exécuter le consommateur en tant que pod Kubernetes normal en supprimant les spécifications skr container et kata-cc runtime class. Puisque vous n'exécutez pas le consommateur avec la classe d'exécution kata-cc, vous n'avez plus besoin de la stratégie.
Supprimez l'ensemble de la politique et observez à nouveau les messages dans le navigateur après avoir redéployé la charge de travail. Les messages apparaissent sous forme de texte chiffré encodé en base64, car la clé de chiffrement privée ne peut pas être récupérée. La clé ne peut pas être récupérée, car le consommateur n'est plus exécuté dans un environnement confidentiel et le skr container est manquant, ce qui empêche le déchiffrement des messages.

Nettoyage

Une fois l’évaluation de cette fonctionnalité terminée, pour éviter les frais Azure, nettoyez vos ressources inutiles. Si, dans le cadre de votre évaluation ou test, vous avez déployé un nouveau cluster, vous pouvez le supprimer à l’aide de la commande az aks delete .

az aks delete --resource-group myResourceGroup --name myAKSCluster

Si vous avez activé les conteneurs confidentiels (préversion) sur un cluster existant, vous pouvez supprimer le(s) pods à l'aide de la commande kubectl delete pod.

kubectl delete pod pod-name

Étapes suivantes

En savoir plus sur les hôtes dédiés Azure pour les nœuds avec votre cluster AKS afin d’utiliser l’isolation matérielle et le contrôle des événements de maintenance de la plateforme Azure.

Partager via