Exercice - Affecter une stratégie à un cluster Azure Kubernetes Service
Vous êtes maintenant prêt à configurer des stratégies et des initiatives Azure pour votre cluster Azure Kubernetes Service (AKS).
Dans cette unité, vous déployez un pod non conforme et appliquez une stratégie Azure qui met en œuvre l’utilisation de registres approuvés uniquement. Ensuite, vous déployez un autre pod non conforme pour vérifier l’effet de la stratégie. Vous découvrez les étapes à suivre pour résoudre les problèmes et voyez pourquoi les pods ne sont pas créés. Vous déployez également l’initiative Standards restreints de sécurité des pods de cluster Kubernetes pour des charges de travail basées sur Linux.
Remarque
Cet exercice est facultatif. Si vous souhaitez effectuer cet exercice, vous devrez créer un abonnement Azure avant de commencer. Si vous n’avez pas de compte Azure ou si vous ne souhaitez pas en créer un pour l’instant, vous pouvez lire les instructions pour comprendre les informations qui sont présentées.
Déployer un pod non conforme dans le cluster
Nous commençons par déployer une image directement depuis Docker Hub dans le cluster. La première étape consiste à se connecter au cluster.
Dans Cloud Shell, connectez-vous au cluster AKS.
az aks get-credentials -n videogamecluster -g videogamergExécutez le code suivant pour créer un pod simple-nginx depuis Docker Hub.
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: simple-nginx labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFExécutez le code suivant pour déployer le service et exposer le déploiement.
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: simple-nginx labels: app: nginx spec: type: LoadBalancer ports: - port: 80 selector: app: nginx EOFLister tous les services déployés.
kubectl get servicesCopiez l’IP externe du service nginx simple et collez-la dans votre navigateur pour voir si le service s’exécute comme prévu.
Si l’IP externe est listée comme
<pending>, réexécutez la commande. L’allocation d’une adresse IP publique pour votre charge de travail prend du temps.
Appliquer une politique Azure au cluster AKS
Vous avez réussi à déployer votre charge de travail sur un cluster sur lequel aucune stratégie n’est appliquée. Maintenant, vous pouvez ajouter une stratégie au cluster et voir comment cela l’affecte.
Attribution d’une stratégie
Vous souhaitez vous assurer que seules les images de certains registres sont autorisées dans le cluster. Vous devez créer une définition de stratégie, puis l’attribuer à une étendue. Dans ce cas, l’étendue est notre groupe de ressources videogamerg. Les stratégies peuvent être créées et attribuées dans le portail Azure, Azure PowerShell ou Azure CLI. Cet exercice vous guide tout au long de la création d’une stratégie dans le portail.
Recherchez les définitions de stratégie intégrées pour la gestion de votre cluster à l’aide du portail Azure en procédant comme suit. Dans ce cas, vous appliquez la stratégie « uniquement les images autorisées ».
Accédez à la page Stratégie dans le portail Azure.
Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
Dans la zone de liste déroulante Catégorie, utilisez Sélectionner tout pour effacer le filtre, puis sélectionnez Kubernetes.
Sélectionnez la définition de stratégie Les conteneurs de cluster Kubernetes doivent utiliser uniquement les images autorisées.
Cliquez sur le bouton Affecter.
Définissez l’étendue sur le groupe de ressources du cluster Kubernetes que vous avez créé, qui est ici le groupe de ressources videogamerg.
Entrez ce qui suit dans le champ Regex des images conteneur autorisées, puis sélectionnez le bouton Vérifier + créer
.+\.azurecr\.io/.+$
- Cliquez sur le bouton Créer.
Maintenant que la nouvelle stratégie est activée, vous pouvez sélectionner Affectations pour voir la stratégie attribuée, puis sélectionner l’affectation de stratégie que vous avez créée.
Votre affectation de stratégie doit ressembler à l’image suivante. L’effet est défini sur refus par défaut. Cela signifie que seules les images hébergées dans Azure Container Registry peuvent être déployées dans le cluster.
Affecter une initiative de stratégie
Maintenant que vous avez réussi à affecter votre stratégie, vous attribuez une initiative avant de tester les stratégies. Une initiative Azure Policy est une collection de définitions ou de règles Azure Policy regroupées pour atteindre un objectif spécifique. Les initiatives Azure simplifient la gestion de vos stratégies en regroupant un ensemble de stratégies, de manière logique, en tant qu’élément unique.
Les initiatives peuvent être affectées de la même façon que les stratégies. Suivez ces étapes pour attribuer l’initiative Standards restreints de sécurité des pods de cluster Kubernetes pour des charges de travail basées sur Linux.
- Revenez à la page Stratégie dans le portail Azure.
- Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
- Dans la zone de liste déroulante Catégorie, utilisez Sélectionner tout pour effacer le filtre, puis sélectionnez Kubernetes.
- Sélectionnez la définition d’initiative Standards restreints de sécurité des pods de cluster Kubernetes pour les charges de travail basées sur Linux. Prenez le temps de regarder les différentes stratégies qui font partie de l’initiative.
- Sélectionnez le bouton Affecter en haut à gauche de l’écran.
- Définissez l’étendue sur le groupe de ressources du cluster Kubernetes que vous avez créé, qui est ici videogamerg. Remplissez le reste du formulaire comme vous l’avez fait à l’étape précédente, puis sélectionnez Vérifier + créer.
- Cliquez sur le bouton Créer.
Ici, vous pouvez retrouver l’affectation de stratégie en cliquant sur Stratégie, puis en sélectionnant Affectations. Cliquez sur l’affectation de stratégie que vous avez créée pour vérifier que l’effet est défini sur Audit dans ce cas.
Tester la stratégie Azure
Maintenant que la stratégie restrictive est affectée au cluster, vous pouvez exécuter un test pour vérifier si elle fonctionne. Pour illustrer cela, créons un déploiement et voyons s’il fonctionne. Commençons par créer un nouveau fichier manifeste kubernetes et le déployer.
Important
Notez que l’entrée en vigueur des affectations de stratégie peut prendre jusqu’à 30 minutes. En raison de ce délai, dans les étapes suivantes, la validation de stratégie peut réussir et le déploiement n’échouera pas. Si cela se produit, prévoyez du temps supplémentaire et recommencez votre déploiement.
Vous pouvez vérifier si l’affectation de stratégie est effective en exécutant la commande suivante.
kubectl get ConstraintTemplates
Vous devez voir un résultat similaire à la sortie suivante. Si vous voyez k8sazurecontainerallowedimages dans la liste, vous savez que votre stratégie est effective.
k8sazureallowedcapabilities 40m
k8sazureallowedseccomp 20m
k8sazureallowedusersgroups 40m
k8sazureblockautomounttoken 40m
k8sazureblockdefault 40m
k8sazureblockhostnamespace 40m
k8sazurecontainerallowedimages 40m
k8sazurecontainerallowedports 40m
k8sazurecontainerlimits 40m
k8sazurecontainernoprivilege 40m
k8sazurecontainernoprivilegeescalation 40m
k8sazuredefenderblockvulnerableimages 40m
k8sazuredisallowedcapabilities 40m
k8sazureenforceapparmor 40m
k8sazurehostfilesystem 40m
k8sazurehostnetworkingports 40m
k8sazureingresshttpsonly 40m
k8sazurereadonlyrootfilesystem 40m
k8sazureserviceallowedports 40m
k8sazurevolumetypes 20m
Créer un autre déploiement et service
nginxà l’aide du code suivant.cat <<EOF | kubectl create -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: docker.io/library/nginx:stable resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFCréer le service
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Service metadata: name: second-simple-nginx labels: app: second-nginx spec: type: LoadBalancer ports: - port: 80 selector: app: second-nginx EOFVous pouvez maintenant vérifier si le pod est créé.
kubectl get pods
Dans la sortie suivante, même le déploiement semble être créé, le pod n’est pas créé. La stratégie que vous avez créée a bloqué le déploiement. Toutefois, le pod qui a été créé avant l’affectation de la stratégie n’a pas été arrêté. La stratégie n’a pas non plus empêché le service d’être créé. Si vous essayez d’ouvrir l’IP EXTERNE dans un navigateur, vous n’obtenez aucune réponse, ce qui indique que le déploiement a échoué.
NAME READY STATUS RESTARTS AGE
simple-nginx-66d884c498-msbpc 1/1 Running 0 63m
Diagnostiquer la raison pour laquelle le pod n’a pas été déployé
Dans la section précédente, nous avons remarqué que le deuxième pod n’a pas été déployé. Dans cette section, nous utilisons la ligne de commande pour en diagnostiquer la raison.
Commençons par décrire le déploiement. Nous voyons que le ReplicaSet est créé, mais que les réplicas n’ont pas été créés.
kubectl get replicasetsLa sortie doit ressembler à l’exemple suivant :
NAME DESIRED CURRENT READY AGE second-simple-nginx-64969b4566 1 0 0 8m45s simple-nginx-66d884c498 1 1 1 72mEnsuite, nous décrivons le ReplicaSet qui a échoué. Copiez le nom du ReplicaSet qui commence par
second-simple-nginx, mettez à jour la commande suivante avec cette valeur et exécutez-la.kubectl describe replicaset <ReplicaSet name>La sortie de la commande indique que les réplicas ont échoué en raison de la stratégie.
Warning FailedCreate 3m9s (x18 over 14m) replicaset-controller Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-container-allowed-images-bcfbd5e1e78f7c8b4104] Container image docker.io/library/nginx:stable for container second-simple-nginx has not been allowed.
Supprimez le déploiement pour préparer l’étape suivante.
kubectl delete deployment second-simple-nginx
Redéploiement des pods à l’aide d’une image Azure Container Registry
Maintenant, vous savez que la stratégie empêche la création d’images depuis Docker Hub dans votre cluster en fonction de votre stratégie. Essayons de redéployer la même charge de travail à l’aide d’une image d’Azure Container Registry (ACR). Dans cette section, vous créez un registre de conteneurs Azure. Puis, vous copiez l’image nginx depuis Docker Hub vers le nouveau registre et essayez de redéployer le pod de votre registre de conteneurs. Nous utilisons Azure CLI pour créer le registre de conteneurs.
Revenez à Cloud Shell dans le portail Azure et entrez les commandes suivantes pour créer un registre de conteneurs.
ACR_NAME=videogameacr$RANDOM az acr create --name $ACR_NAME \ --resource-group videogamerg \ --sku PremiumImporter l’image depuis Docker Hub vers votre nouveau registre de conteneurs.
az acr import --name $ACR_NAME --source docker.io/library/nginx:stable --image nginx:v1Vérifiez que l’image a été importée. Vous devez voir nginx dans la liste des résultats.
az acr repository list --name $ACR_NAMELiez votre cluster AKS au registre de conteneurs que vous avez créé.
az aks update -n videogamecluster -g videogamerg --attach-acr $ACR_NAMEMaintenant, créez le déploiement à l’aide de votre registre de conteneurs nouvellement créé en exécutant la commande suivante.
cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: second-simple-nginx labels: app: second-nginx spec: selector: matchLabels: app: second-nginx template: metadata: labels: app: second-nginx spec: containers: - name: second-simple-nginx image: ${ACR_NAME}.azurecr.io/nginx:v1 resources: requests: cpu: 100m memory: 100Mi limits: cpu: 120m memory: 120Mi ports: - containerPort: 80 EOFObtenez l’IP EXTERNE afin de vérifier si le service s’exécute dans le cluster.
kubectl get pods kubectl get services
Copiez l’adresse IP externe et collez-la dans le navigateur. Vous voyez que la page se charge maintenant.
Utiliser des stratégies pour imposer des normes
Dans cette unité, vous avez vu comment utiliser des stratégies pour vous assurer que votre cluster autorise uniquement le déploiement d’images d’Azure Container Registry. Vous avez également vu comment ajouter l’une des initiatives intégrées qui peuvent vous aider à gérer facilement votre cluster et à mieux le sécuriser. Toutefois, vous avez vu que le pod qui a été déployé avant l’affectation de la stratégie continue à s’exécuter. Dans l’unité suivante, vous voyez comment vérifier la conformité des pods qui s’exécutent sur le cluster.