Sécuriser votre cluster à l’aide de stratégies de sécurité des pods dans Azure Kubernetes Service (AKS) (préversion)

Important

La fonctionnalité stratégie de sécurité des pods est déconseillée depuis le 1er août 2023 et a été supprimée d’AKS version1.25 (et les versions ultérieures).

Nous vous recommandons d’effectuer une migration vers le contrôleur d’admission de sécurité des pods ou la stratégie Azure pour continuer à bénéficier du support Azure. L’admission de la sécurité des pods est une solution de stratégie intégrée pour les implémentations de cluster uniques. Si vous recherchez une stratégie de niveau entreprise, une stratégie Azure est un meilleur choix.

Avant de commencer

• Cet article suppose que vous disposez d’un cluster AKS. Si vous avez besoin d’un cluster AKS, créez-en un à l'aide d’Azure CLI, d’Azure PowerShell ou du portail Azure.
• L’interface de ligne de commande Azure (Azure CLI) version 2.0.61 ou une version ultérieure doit avoir été installée et configurée. Exécutez az --version pour trouver la version. Si vous devez l’installer ou le mettre à niveau, consultez Installation d’Azure CLI.

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 :

• Stratégies de support AKS
• FAQ du support Azure

1. Installez l’extension aks-preview à l’aide de la commande az extension add.

   az extension add --name aks-preview
   

2. Mettez à jour vers la dernière version de l’extension à l’aide de la commande az extension update.

   az extension update --name aks-preview
   

Inscrire l’indicateur de fonctionnalité PodSecurityPolicyPreview

1. Inscrivez l’indicateur de fonctionnalité PodSecurityPolicyPreview à l’aide de la commande az feature register.

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

   Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

2. Vérifiez l’état de l’inscription en utilisant la commande az feature show.

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

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

Présentation des stratégies de sécurité des pods

Les clusters Kubernetes utilisent des contrôleurs d’admission pour intercepter les requêtes envoyées au serveur d’API quand une ressource doit être créée. Le contrôleur d’admission peut ensuite valider la requête de ressource par rapport à un ensemble de règles, ou muter la ressource à modifier les paramètres de déploiement.

PodSecurityPolicy est un contrôleur d’admission qui confirme si une spécification de pod répond à vos besoins définis. Ces exigences peuvent limiter l’utilisation de conteneurs privilégiés, l’accès à certains types de stockage, ou l’utilisateur/groupe sous lequel le conteneur peut s’exécuter. Lorsque vous tentez de déployer une ressource où les spécifications de pod ne répondent pas aux exigences décrites dans la stratégie de sécurité des pods, la requête est refusée. Ce contrôle sur les pods pouvant être planifiés dans le cluster AKS empêche d’éventuelles vulnérabilités de sécurité ou escalades de privilèges.

Lorsque vous activez la stratégie de sécurité des pods dans un cluster AKS, certaines stratégies par défaut sont appliquées. Ces stratégies fournissent une expérience prête à l’emploi pour définir les pods à planifier. Toutefois, vous pouvez rencontrer des problèmes de déploiement de vos pods jusqu’à ce que vous définissiez vos propres stratégies. L'approche recommandée consiste à :

1. Créez un cluster AKS.
2. Définir vos propres stratégies de sécurité des pods.
3. Activer la fonctionnalité de stratégie de sécurité des pods.

Changements de comportement entre la stratégie de sécurité des pods et Azure Policy

Scénario	Stratégie de sécurité des pods	Azure Policy
Installation	Activez la fonctionnalité de stratégie de sécurité des pods	Installez le module complémentaire Azure Policy
Déployer des stratégies	Déployer la ressource de stratégie de sécurité des pods	Affectez des stratégies Azure à l’étendue de l’abonnement ou du groupe de ressources. Le module complémentaire Azure Policy est requis pour les applications de ressources Kubernetes.
Stratégies par défaut	Lorsque la stratégie de sécurité des pods est activée dans AKS, les stratégies privilégiées et non restreintes par défaut sont appliquées.	Après l’activation du module complémentaire Azure Policy, aucune stratégie n’est appliquée par défaut. Vous devez explicitement activer les stratégies dans Azure Policy.
Qui peut créer et attribuer une stratégie	L’administrateur de cluster crée une ressource de stratégie de sécurité des pods	Les utilisateurs doivent avoir un rôle minimal d’autorisations « propriétaire » ou « contributeur de stratégie de ressource » sur le groupe de ressources du cluster AKS. - Via l’API, les utilisateurs peuvent affecter des stratégies dans l’étendue de la ressource de cluster AKS. Les utilisateurs doivent avoir un rôle minimal d’autorisations « propriétaire » ou « contributeur de stratégie de ressource » sur le groupe de ressources du cluster AKS. - Dans le portail Azure, les stratégies peuvent être appliquées au niveau du groupe d’administration, de l’abonnement ou du groupe de ressources.
Autorisation des stratégies	Les utilisateurs et les comptes de service requièrent des autorisations explicites pour utiliser des stratégies de sécurité des pods.	Aucune affectation supplémentaire n’est requise pour autoriser des stratégies. Une fois les stratégies affectées dans Azure, tous les utilisateurs du cluster peuvent utiliser ces stratégies.
Applicabilité de la stratégie	L’utilisateur administrateur ignore la mise en œuvre des stratégies de sécurité des pods.	Tous les utilisateurs (administrateur et non-administrateur) voient les mêmes stratégies. Il n’existe aucune casse particulière basée sur les utilisateurs. L’application de stratégie peut être exclue au niveau de l’espace de noms.
Étendue de la stratégie	Les stratégies de sécurité des pods n’ont pas d’espace de noms.	Les modèles de contrainte utilisés par Azure Policy n’ont pas d’espace de noms.
Action Refus/Audit/Mutation	Les stratégies de sécurité des pods prennent uniquement en charge les actions de refus. La mutation peut être effectuée avec des valeurs par défaut sur les demandes de création. La validation peut être effectuée pendant les demandes de mise à jour.	Azure Policy prend en charge les actions d’audit et de refus. La mutation n’est pas encore prise en charge.
Conformité à la stratégie de sécurité des pods	Il n’existe aucune visibilité sur la conformité des pods qui existaient avant l’activation de la stratégie de sécurité des pods. Les pods non conformes créés après l’activation des stratégies de sécurité des pods sont refusés.	Les pods non conformes qui existaient avant l’application des stratégies Azure s’affichent dans les violations de stratégie. Les pods non conformes créées après l’activation des stratégies Azure sont refusées si les stratégies sont définies avec un effet de refus.
Comment afficher les stratégies sur le cluster	kubectl get psp	kubectl get constrainttemplate -Toutes les stratégies sont retournées.
Norme de stratégie de sécurité des pods - Privilégiée	Une ressource de stratégie de sécurité des pods privilégiée est créée par défaut lors de l’activation de la fonctionnalité.	Le mode Privilégié n’implique aucune restriction. Par conséquent, il équivaut à ne pas avoir d’affectation Azure Policy.
Norme de stratégie de sécurité des pods - Ligne de base/Par défaut	L’utilisateur installe une ressource de ligne de base de stratégie de sécurité des pods.	Azure Policy fournit une initiative de ligne de base intégrée qui correspond à la stratégie de sécurité des pods de base.
Norme de stratégie de sécurité des pods - Restreinte	L’utilisateur installe une ressource de ligne de base pour la stratégie de sécurité des pods.	Azure Policy fournit une initiative de ligne de base intégrée qui correspond à la stratégie de sécurité des pods restreinte.

Activer la stratégie de sécurité des pods sur un cluster AKS

Notes

Pour une utilisation en conditions réelles, n’activez pas la stratégie de sécurité des pods tant que vous n’avez pas défini vos propres stratégies personnalisées. Dans cet article, nous activons la stratégie de sécurité des pods en tant que première étape pour voir comment les stratégies par défaut limitent les déploiements de pods.

• Activez la stratégie de sécurité des pods à l’aide de la commande az aks update.

  az aks update \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --enable-pod-security-policy
  

Stratégies AKS par défaut

Lorsque vous activez la stratégie de sécurité des pods, AKS crée une seule stratégie par défaut nommée privileged. Ne modifiez pas et ne supprimez pas cette stratégie par défaut. Créez plutôt vos propres stratégies qui définissent les paramètres souhaités pour le contrôle. Nous allons examiner ces stratégies par défaut et observer leur impact sur les déploiements de pods.

1. Affichez les stratégies disponibles à l’aide de la commande kubectl get psp.

   kubectl get psp
   

   La sortie ressemble à l’exemple suivant :

   NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
   

   La stratégie de sécurité des pods privileged est appliquée à tout utilisateur authentifié dans le cluster AKS. Cette affectation est contrôlée par ClusterRoles et ClusterRoleBindings.

2. Recherchez la liaison default:privileged: dans l’espace de noms kube-system à l’aide de la commande kubectl get rolebindings.

   kubectl get rolebindings default:privileged -n kube-system -o yaml
   

   L’exemple de sortie condensée suivant affiche le ClusterRole psp:privileged attribué à tous les utilisateurs system:authenticated. Cette capacité offre un niveau de base pour les privilèges sans avoir à définir vos propres stratégies.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     [...]
     name: default:privileged
     [...]
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp:privileged
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   

Il est important de comprendre comment ces stratégies par défaut interagissent avec les requêtes des utilisateurs pour planifier les pods avant de commencer à créer vos propres stratégies de sécurité des pods. Dans les sections suivantes, nous planifions des pods pour voir les stratégies par défaut en action.

Créer un utilisateur de test dans un cluster AKS

Quand vous utilisez la commande az aks get-credentials, les informations d’identification administrateur du cluster AKS sont ajoutées par défaut à votre configuration kubectl. L’utilisateur administrateur ignore la mise en œuvre des stratégies de sécurité des pods. Si vous utilisez l’intégration Microsoft Entra pour vos clusters AKS, vous pouvez vous connecter avec les informations d’identification d’un utilisateur non-administrateur pour voir l’application des stratégies en action.

1. Créer un espace de noms exemple nommé psp-aks pour les ressources de test à l’aide de la commande kubectl create namespace.

   kubectl create namespace psp-aks
   

2. Créez un compte de service nommé nonadmin-user à l’aide de la commande kubectl create serviceaccount.

   kubectl create serviceaccount --namespace psp-aks nonadmin-user
   

3. Créez un RoleBinding pour le compte nonadmin-user afin d’effectuer des actions de base dans l’espace de noms à l’aide de la commande kubectl create rolebinding.

   kubectl create rolebinding \
       --namespace psp-aks \
       psp-aks-editor \
       --clusterrole=edit \
       --serviceaccount=psp-aks:nonadmin-user
   

Créer des commandes d’alias pour l’utilisateur administrateur et non-administrateur

Quand vous utilisez kubectl, vous pouvez mettre en évidence les différences entre l’utilisateur administrateur normal et l’utilisateur non-administrateur en créant deux alias de ligne de commande :

1. L’alias kubectl-admin destiné à l’utilisateur administrateur normal, qui est limité à l’espace de noms psp-aks.
2. L’alias kubectl-nonadminuser destiné au compte nonadmin-user créé à l’étape précédente, qui est limité à l’espace de noms psp-aks.

• Créez les deux alias à l’aide des commandes suivantes.

  alias kubectl-admin='kubectl --namespace psp-aks'
  alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'
  

Tester la création d’un pod privilégié

Testons ce qui se passe quand vous planifiez un pod avec le contexte de sécurité privileged: true. Ce contexte de sécurité fait remonter les privilèges du pod. La stratégie de sécurité AKS privilege par défaut doit refuser cette demande.

1. Créez un fichier nommé nginx-privileged.yaml et collez le contenu du manifeste YAML suivant.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged
   spec:
     containers:
       - name: nginx-privileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           privileged: true
   

2. Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   L’exemple de sortie suivant montre que la planification du pod a échoué :

   Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
   

   Il n’existe aucune ressource à supprimer avant de poursuivre, car le pod n’atteint pas la phase de planification.

Tester la création d’un pod non privilégié

Dans l’exemple précédent, la spécification de pod a demandé une élévation des privilèges. Cette requête est refusée par la stratégie de sécurité des pods privilege par défaut. Il est donc impossible de planifier le pod. Essayons d’exécuter le même pod NGINX sans la requête d’élévation des privilèges.

1. Créez un fichier nommé nginx-unprivileged.yaml et collez le contenu du manifeste YAML suivant.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
   

2. Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   L’exemple de sortie suivant montre que la planification du pod a échoué :

   Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
   

   Il n’existe aucune ressource à supprimer avant de poursuivre, car le pod n’atteint pas la phase de planification.

Tester la création d’un pod avec un contexte utilisateur spécifique

Dans l’exemple précédent, l’image de conteneur tentait automatiquement d’utiliser la racine pour lier NGINX au port 80. Cette requête était refusée par la stratégie de sécurité des pods privilege par défaut. Il était donc impossible de planifier le pod. Essayons d’exécuter le même pod NGINX avec un contexte utilisateur spécifique, tel que runAsUser: 2000.

1. Créez un fichier nommé nginx-unprivileged-nonroot.yaml et collez le manifeste YAML suivant.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged-nonroot
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           runAsUser: 2000
   

2. Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
   

   L’exemple de sortie suivant montre que la planification du pod a échoué :

   Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []
   

   Il n’existe aucune ressource à supprimer avant de poursuivre, car le pod n’atteint pas la phase de planification.

Créer une stratégie de sécurité des pods personnalisée

Maintenant que vous avez vu le comportement des stratégies de sécurité des pods par défaut, donnons les moyens à nonadmin-user de planifier correctement des pods.

Nous allons créer une stratégie pour rejeter les pods qui demandent un accès privilégié. Les autres options, telles que runAsUser ou les volumes autorisés, ne sont pas explicitement limitées. Ce type de stratégie refuse une requête d’accès privilégié, mais elle permet au cluster d’exécuter les pods demandés.

1. Créez un fichier nommé psp-deny-privileged.yaml et collez le manifeste YAML suivant.

   apiVersion: policy/v1beta1
   kind: PodSecurityPolicy
   metadata:
     name: psp-deny-privileged
   spec:
     privileged: false
     seLinux:
       rule: RunAsAny
     supplementalGroups:
       rule: RunAsAny
     runAsUser:
       rule: RunAsAny
     fsGroup:
       rule: RunAsAny
     volumes:
    - '*'
   

2. Créez la stratégie à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl apply -f psp-deny-privileged.yaml
   

3. Affichez les stratégies disponibles à l’aide de la commande kubectl get psp.

   kubectl get psp
   

   Dans l’exemple de sortie suivant, comparez la stratégie psp-deny-privileged à la stratégie privilege par défaut appliquée dans les exemples précédents de création d’un pod. Seule l’utilisation de l’escalade PRIV est refusée par votre stratégie. Il n’existe aucune restriction sur l’utilisateur ou le groupe pour la stratégie psp-deny-privileged.

   NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
   psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *          
   

Autoriser le compte d’utilisateur à utiliser la stratégie de sécurité des pods personnalisée

À l’étape précédente, vous avez créé une stratégie de sécurité des pods qui refuse les pods demandant un accès privilégié. Pour permettre l’utilisation de la stratégie, vous créez un rôle ou un ClusterRole. Ensuite, vous associez un de ces rôles à l’aide de RoleBinding ou ClusterRoleBinding. Pour cet exemple, nous allons créer un ClusterRole qui vous permet d’utiliser la stratégie psp-deny-privileged créée à l’étape précédente.

1. Créez un fichier nommé psp-deny-privileged-clusterrole.yaml et collez le manifeste YAML suivant.

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: psp-deny-privileged-clusterrole
   rules:
   - apiGroups:
     - extensions
      resources:
     - podsecuritypolicies
      resourceNames:
     - psp-deny-privileged
      verbs:
     - use
   

2. Créez le ClusterRole à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl apply -f psp-deny-privileged-clusterrole.yaml
   

3. Créez un fichier nommé psp-deny-privileged-clusterrolebinding.yaml et collez le manifeste YAML suivant.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: psp-deny-privileged-clusterrolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp-deny-privileged-clusterrole
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   

4. Créez le ClusterRoleBinding à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
   

Notes

À la première étape de cet article, la fonctionnalité de stratégie de sécurité des pods a été activée sur le cluster AKS. La pratique recommandée consistait à activer uniquement la fonctionnalité de stratégie de sécurité des pods après avoir défini vos propres stratégies. Il s’agit du stade où vous devez activer la fonctionnalité de stratégie de sécurité des pods. Au moins une stratégie personnalisée a été définie, et les comptes d’utilisateur ont été associés à ces stratégies. Vous pouvez à présent activer en toute sécurité la fonctionnalité de stratégie de sécurité des pods et réduire les problèmes causés par les stratégies par défaut.

Retester la création d’un pod non privilégié

Avec votre stratégie de sécurité des pods personnalisée appliquée et une liaison permettant au compte d’utilisateur d’utiliser la stratégie, nous allons essayer à nouveau de créer un pod non privilégié.

Cet exemple montre comment vous pouvez créer des stratégies de sécurité des pods personnalisées pour définir l’accès au cluster AKS pour différents utilisateurs ou groupes. Les stratégies AKS par défaut fournissent un contrôle strict quant aux pods autorisés à exécuter. Par conséquent, créez vos propres stratégies personnalisées, puis définissez correctement les restrictions dont vous avez besoin.

1. Utilisez le manifeste nginx-privileged.yaml pour créer le pod à l’aide de la commande kubectl apply.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. Vérifiez l’état du pod à l’aide de la commande kubectl get pods.

   kubectl-nonadminuser get pods
   

   L’exemple de sortie suivant montre que le pod a été correctement planifié et est en cours d’exécution :

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          7m14s
   

3. Supprimez le pod non privilégié NGINX à l’aide de la commande kubectl delete et spécifiez le nom de votre manifeste YAML.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Nettoyer les ressources

1. Désactivez la stratégie de sécurité des pods à l’aide de la commande az aks update.

   az aks update \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --disable-pod-security-policy
   

2. Supprimez le ClusterRole et le ClusterRoleBinding à l’aide de la commande kubectl delete.

   kubectl delete -f psp-deny-privileged-clusterrole.yaml
   

3. Supprimez le ClusterRoleBinding à l’aide de la commande kubectl delete.

   kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
   

4. Supprimez la stratégie de sécurité à l’aide de la commande kubectl delete et spécifiez le nom de votre manifeste YAML.

   kubectl delete -f psp-deny-privileged.yaml
   

5. Supprimez l’espace de noms psp-aks à l’aide de la commande kubectl delete.

   kubectl delete namespace psp-aks
   

Étapes suivantes

Cet article vous a montré comment créer une stratégie de sécurité des pods pour empêcher l’utilisation de l’accès privilégié. Les stratégies peuvent appliquer un grand nombre de fonctionnalités, telles que le type de volume ou l’utilisateur RunAs. Pour plus d’informations sur les options disponibles, consultez les documents de référence sur les stratégies de sécurité des pods Kubernetes.

Pour plus d’informations sur la limitation du trafic réseau des pods, consultez Sécuriser le trafic entre les pods avec des stratégies réseau dans AKS.