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

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

Vous avez besoin des ressources suivantes installées et configurées avant de commencer :

• 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.
• Terraform version 1.6.0 ou ultérieure.
• Azure CLI version 2.47.0 ou ultérieure. Pour installer ou mettre à jour Azure CLI, consultez Installer Azure CLI.
• Kubectl installé et configuré.

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

1. Accédez au service Azure Policy dans le portail Azure 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 afin de bloquer les nouveaux déploiements non conformes à l’initiative de référence. 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éez un répertoire pour la configuration Terraform.

mkdir aks-use-azure-policy
cd aks-use-azure-policy

Créer la configuration Terraform

Créez un fichier appelé main.tf.

touch main.tf

Ouvrez le main.tf fichier et ajoutez la configuration suivante.

Configurer le fournisseur Terraform

Configuration suivante :

• Définit la version Terraform.
• Configure le fournisseur AzureRM.
• Active les fonctionnalités du fournisseur Azure requises pour la gestion des ressources.

terraform {
 required_version = ">= 1.6.0"
 required_providers {
   azurerm = {
     source  = "hashicorp/azurerm"
     version = "~> 4.0"
   }
 }
}
provider "azurerm" {
 features {}
}

Définir des variables d’entrée

Utilisez les variables suivantes pour fournir le nom du groupe de ressources existant et du cluster AKS pendant le déploiement.

variable "resource_group_name" {
 description = "Name of the resource group that contains the existing AKS cluster."
 type        = string
}
variable "aks_cluster_name" {
 description = "Name of the existing AKS cluster."
 type        = string
}

Faire référence au cluster AKS existant

Les sources de données suivantes récupèrent des informations sur le groupe de ressources existant et le cluster AKS. Terraform utilise ces données pour référencer l’infrastructure qui existe déjà dans Azure au lieu de créer de nouvelles ressources.

data "azurerm_resource_group" "aks" {
 name = var.resource_group_name
}
data "azurerm_kubernetes_cluster" "aks" {
 name                = var.aks_cluster_name
 resource_group_name = data.azurerm_resource_group.aks.name
}

Facultatif : Créer et affecter une définition de stratégie personnalisée

La section définition de stratégie personnalisée est informationnelle et se trouve en dehors de l’étendue de cet article. 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 :

• Pratiques de sécurité.
• Gestion des coûts.
• Règles spécifiques à l’organisation, telles que les conventions d’affectation de noms ou les 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.

Après avoir créé votre définition de stratégie personnalisée, consultez Affecter une définition de stratégie pour une procédure pas à pas pour affecter la stratégie à votre cluster.

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

kubectl get constrainttemplates

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é

Testez ce qui se passe lorsque vous programmez un pod avec le contexte de sécurité de 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 kubectl apply commande 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 rejette cette requête, si bien que le pod ne parvient pas à démarrer. À présent, essayez d’exécuter ce même NGINX pod sans accès privilégié.

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

   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 kubectl apply commande 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 kubectl get pods commande.

   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 NGINX pod non privilégié à l’aide de la kubectl delete commande et spécifiez le nom de votre manifeste YAML.

   kubectl delete -f nginx-unprivileged.yaml
   

Procédez comme suit pour affecter une initiative de Azure Policy intégrée à votre cluster AKS à l’aide de Terraform.

Récupérer l’initiative intégrée Azure Policy

La source de données suivante récupère l’initiative intégrée Azure Policy pour les normes de base de référence de sécurité des pods Kubernetes.

data "azurerm_policy_set_definition" "aks_pod_security_baseline" {
 display_name = "Kubernetes cluster pod security baseline standards for Linux-based workloads"
}

Attribuer l’initiative Azure Policy

La ressource suivante affecte l’initiative Azure Policy intégrée au groupe de ressources qui contient le cluster AKS.

Définissez l’effet de la stratégie sur Deny afin de bloquer les charges de travail qui violent les règles de la stratégie définies.

resource "azurerm_resource_group_policy_assignment" "aks_pod_security_baseline" {
 name                 = "aks-pod-security-baseline"
 display_name         = "Kubernetes cluster pod security baseline standards for Linux-based workloads"
 resource_group_id    = data.azurerm_resource_group.aks.id
 policy_definition_id = data.azurerm_policy_set_definition.aks_pod_security_baseline.id
 parameters = jsonencode({
   effect = {
     value = "Deny"
   }
 })
}

Initialiser la configuration Terraform

Exécutez terraform init pour initialiser le répertoire de travail Terraform et télécharger les plug-ins de fournisseur requis.

terraform init

Mettre en forme et valider la configuration

Exécutez terraform fmt pour mettre en forme la configuration Terraform.

terraform fmt

Exécutez terraform validate pour valider la syntaxe de configuration Terraform.

terraform validate

Appliquer la configuration Terraform

Avant de déployer la configuration, fournissez des valeurs pour les variables suivantes :

• resource_group_name
• aks_cluster_name

Exécutez terraform apply pour déployer l’affectation de Azure Policy.

terraform apply

Lorsque vous y êtes invité, entrez yes pour confirmer le déploiement.

Vérifier l’installation de Azure Policy

Une fois le déploiement terminé, vérifiez que les composants Azure Policy s’exécutent dans le cluster AKS.

kubectl get pods -n kube-system

Vérifiez que les modèles de contrainte Gatekeeper ont été installés correctement.

kubectl get constrainttemplates

Tester l’affectation de Azure Policy

Créez un fichier appelé privileged-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
 name: privileged-pod
spec:
 containers:
 - name: nginx
   image: nginx
   securityContext:
     privileged: true

Appliquez le manifeste au cluster.

kubectl apply -f privileged-pod.yaml

Le déploiement échoue, car l’affectation Azure Policy refuse les conteneurs privilégiés qui ne respectent pas les normes de base de référence de sécurité des pods configurées.

Désactiver une stratégie ou une initiative

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

1. Accédez au volet Stratégie dans le portail Azure.
2. Sélectionnez Affectations.
3. Sélectionnez les points de suspension (...) à la fin de la ligne 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.

Pour supprimer le module complémentaire Azure Policy de votre cluster AKS, consultez Supprimer le module complémentaire.

É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
• Supprimer le module complémentaire