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

Article
06/25/2023

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 :

Dans le portail Azure, accédez au service Azure Policy, appelé Stratégie.
Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
Sous Catégories, sélectionnez Kubernetes.
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.
Sélectionnez Attribuer.
Définissez l’étendue du groupe de ressources du cluster AKS avec le module complémentaire Azure Policy activé.
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.
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.

Notes

Azure Policy utilise désormais une nouvelle propriété appelée templateInfo qui vous permet de définir le type de source du modèle de contrainte. Lorsque vous définissez templateInfo dans les définitions de stratégie, vous n’avez pas à définir constraintTemplate ni les propriétés constraint. Vous devez toujours définir les apiGroups et les types. Pour plus d’informations à ce sujet, consultez Présentation des effets Azure Policy.

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.

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

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é.

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

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
```
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.
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 :

Accédez au volet Stratégie sur le portail Azure.
Sélectionnez Affectations.
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.
Sélectionnez Supprimer l’attribution.

Étapes suivantes

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