Sécuriser vos clusters Azure Kubernetes Service (AKS) avec Azure Policy

Vous pouvez appliquer des stratégies de sécurité intégrées sur vos clusters AKS (Azure Kubernetes Service) à l’aide d’Azure Policy. Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Après avoir installé le module complémentaire Azure Policy pour AKS, vous pouvez appliquer des définitions de stratégie individuelles ou des groupes de définitions de stratégie appelés initiatives (parfois appelées ensembles de stratégies) à votre cluster. Pour obtenir la liste complète des définitions d’initiative et de stratégie AKS, consultez Définitions intégrées d’Azure Policy pour Azure Kubernetes Service.

Cet article explique comment appliquer des définitions de stratégie à votre cluster et vérifier que ces attributions sont appliquées.

Prérequis

• Cet article suppose que vous disposez d’un cluster AKS. Si vous avez besoin d’un cluster AKS, vous pouvez en créer un en utilisant Azure CLI, Azure PowerShell ou le portail Azure.
• Vous devez avoir installé le module complémentaire Azure Policy pour AKS sur votre cluster AKS.

Affecter une définition de stratégie ou une initiative intégrée

Vous pouvez appliquer une définition ou une initiative de stratégie dans le portail Azure en procédant comme suit :

1. Dans le portail Azure, accédez au service Azure Policy, appelé Stratégie.
2. Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
3. Sous Catégories, sélectionnez Kubernetes.
4. Choisissez la définition de stratégie ou l’initiative que vous souhaitez appliquer. Pour cet exemple, sélectionnez l’initiative Normes de référence liées à la sécurité du pod de cluster Kubernetes pour les charges de travail basées sur Linux.
5. Sélectionnez Attribuer.
6. Définissez l’étendue du groupe de ressources du cluster AKS avec le module complémentaire Azure Policy activé.
7. Sélectionnez la page Paramètres et mettez à jour l’Effet de audit à deny pour bloquer les nouveaux déploiements enfreignant l’initiative de base. Vous pouvez également ajouter d’autres espaces de noms à exclure de l’évaluation. Pour cet exemple, conservez les valeurs par défaut.
8. Cliquez sur Vérifier + Créer>Créer pour soumettre l’attribution des stratégies.

Créer et attribuer une définition de stratégie personnalisée

Les stratégies personnalisées vous permettent de définir des règles d’utilisation d’Azure. Par exemple, vous pouvez appliquer les types de règles suivants :

• Des mesures de sécurité
• la gestion des coûts ;
• Des règles propres à l’organisation (par exemple, de nommage ou d’emplacements)

Avant de créer une stratégie personnalisée, consultez la liste des modèles courants et des exemples pour voir si votre cas y est déjà traité.

Les définitions de stratégie personnalisée sont écrites en JSON. Pour en savoir plus sur la création d’une stratégie personnalisée, consultez Structure de définition Azure Policy et Créer une définition de stratégie personnalisée.

Une fois votre définition de stratégie personnalisée créée, consultez Affecter une définition de stratégie pour découvrir comment attribuer la stratégie à votre cluster Kubernetes, étape par étape.

Valider l’exécution d’une stratégie Azure Policy

• Vérifiez que les attributions de stratégies sont appliquées à votre cluster à l’aide de la commande kubectl get suivante.

  kubectl get constrainttemplates
  

  Notes

  Les attributions de stratégies peuvent prendre jusqu’à 20 minutes pour se synchroniser dans chaque cluster.

  Votre résultat devrait être semblable à l’exemple de sortie suivant :

  NAME                                     AGE
  k8sazureallowedcapabilities              23m
  k8sazureallowedusersgroups               23m
  k8sazureblockhostnamespace               23m
  k8sazurecontainerallowedimages           23m
  k8sazurecontainerallowedports            23m
  k8sazurecontainerlimits                  23m
  k8sazurecontainernoprivilege             23m
  k8sazurecontainernoprivilegeescalation   23m
  k8sazureenforceapparmor                  23m
  k8sazurehostfilesystem                   23m
  k8sazurehostnetworkingports              23m
  k8sazurereadonlyrootfilesystem           23m
  k8sazureserviceallowedports              23m
  

Valider le rejet d’un pod privilégié

Nous allons commencer par tester ce qui se passe lorsque vous planifiez un pod avec le contexte de sécurité privileged: true. Ce contexte de sécurité fait remonter les privilèges du pod. L’initiative n’autorise pas les pods privilégiés, de sorte que la requête est refusée, entraînant le rejet du déploiement.

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged
   spec:
     containers:
       - name: nginx-privileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-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 apply -f nginx-privileged.yaml
   

   Comme prévu, la planification du pod échoue, comme indiqué dans l’exemple de sortie suivant :

   Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}
   

   Le pod n'atteint pas la phase de planification ; il n'existe aucune ressource à supprimer avant de poursuivre.

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

Dans l’exemple précédent, l’image de conteneur tentait automatiquement d’utiliser la racine pour lier NGINX au port 80. L’initiative de stratégie refuse cette requête, de sorte que le pod ne démarre pas. Essayons maintenant d’exécuter ce même pod NGINX sans la requête d’accès privilégié.

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

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

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

   kubectl apply -f nginx-unprivileged.yaml
   

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

   kubectl get pods
   

   Votre sortie doit être semblable à l’exemple de sortie suivant, qui montre que le pod est correctement planifié et à l’état En cours d’exécution :

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          18s
   

   Cet exemple montre l’initiative de base qui affecte uniquement les déploiements violant les stratégies de la collection. Les déploiements autorisés continuent à fonctionner.

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

   kubectl delete -f nginx-unprivileged.yaml
   

Désactiver une stratégie ou une initiative

Vous pouvez supprimer l’initiative de base de référence dans le portail Azure en procédant comme suit :

1. Accédez au volet Stratégie sur le portail Azure.
2. Sélectionnez Affectations.
3. Sélectionnez le bouton ... en regard de l’initiative Normes de référence liées à la sécurité du pod de cluster Kubernetes pour les charges de travail basées sur Linux.
4. Sélectionnez Supprimer l’attribution.

Étapes suivantes

Pour plus d’informations sur le fonctionnement d’Azure Policy, consultez les articles suivants :

• Vue d’ensemble d’Azure Policy
• Initiatives et stratégies Azure Policy pour AKS
• Supprimez le module complémentaire Azure Policy.