Aperçu - Sécuriser votre cluster à l’aide de stratégies de sécurité des pods dans Azure Kubernetes Service (AKS)Preview - Secure your cluster using pod security policies in Azure Kubernetes Service (AKS)

Pour améliorer la sécurité de votre cluster AKS, vous pouvez limiter les pods pouvant être planifiés.To improve the security of your AKS cluster, you can limit what pods can be scheduled. Les pods qui demandent des ressources non autorisées ne sont pas exécutés dans le cluster AKS.Pods that request resources you don't allow can't run in the AKS cluster. Vous définissez cet accès à l’aide de stratégies de sécurité des pods.You define this access using pod security policies. Cet article explique comment utiliser des stratégies de sécurité des pods pour limiter le déploiement de pods dans AKS.This article shows you how to use pod security policies to limit the deployment of pods in AKS.

Important

Les fonctionnalités d’évaluation AKS sont en libre-service et font l’objet d’un abonnement.AKS preview features are self-service opt-in. Les versions préliminaires sont fournies « en l’état », « avec toutes les erreurs » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service (sla) et de la garantie limitée.Previews are provided "as-is" and "as available" and are excluded from the service level agreements and limited warranty. Les versions préliminaires AKS sont partiellement couvertes par le service clientèle sur la base du meilleur effort.AKS Previews are partially covered by customer support on best effort basis. En tant que tel, ces fonctionnalités ne sont pas destinées à une utilisation en production.As such, these features are not meant for production use. Pour obtenir des informations supplémentaires, veuillez lire les articles de support suivants :For additional infromation, please see the following support articles:

Avant de commencerBefore you begin

Cet article suppose que vous avez un cluster AKS existant.This article assumes that you have an existing AKS cluster. Si vous avez besoin d’un cluster AKS, consultez le guide de démarrage rapide d’AKS avec Azure CLIou avec le Portail Azure.If you need an AKS cluster, see the AKS quickstart using the Azure CLI or using the Azure portal.

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.You need the Azure CLI version 2.0.61 or later installed and configured. Exécutez  az --version pour trouver la version.Run az --version to find the version. Si vous devez installer ou mettre à niveau, consultez  Installation d’Azure CLI.If you need to install or upgrade, see Install Azure CLI.

Installer l’extension CLI de préversion d’aksInstall aks-preview CLI extension

Pour utiliser des stratégies de sécurité des pods, vous aurez besoin de l’extension de CLI aks-preview version 0.4.1 ou version ultérieure.To use pod security policies, you need the aks-preview CLI extension version 0.4.1 or higher. Installez l’extension Azure CLI aks-preview à l’aide de la commande az extension add, puis recherchez toutes les mises à jour disponibles à l’aide de la commande az extension update :Install the aks-preview Azure CLI extension using the az extension add command, then check for any available updates using the az extension update command:

# Install the aks-preview extension
az extension add --name aks-preview

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Inscrire le fournisseur de fonctionnalités de stratégie de sécurité des podsRegister pod security policy feature provider

Pour créer ou mettre à jour un cluster AKS afin d’utiliser des stratégies de sécurité des pods, commencez par activer un indicateur de fonctionnalité sur votre abonnement.To create or update an AKS cluster to use pod security policies, first enable a feature flag on your subscription. Pour enregistrer l’indicateur de fonctionnalité PodSecurityPolicyPreview, utilisez la commande az feature register, comme indiqué dans l’exemple suivant :To register the PodSecurityPolicyPreview feature flag, use the az feature register command as shown in the following example:

Attention

Lorsque vous inscrivez une fonctionnalité sur un abonnement, vous ne pouvez actuellement pas désinscrire cette fonctionnalité.When you register a feature on a subscription, you can't currently un-register that feature. Après avoir activé des fonctionnalités en préversion, des valeurs par défaut peuvent être utilisées pour tous les clusters AKS créés ultérieurement dans l’abonnement.After you enable some preview features, defaults may be used for all AKS clusters then created in the subscription. N’activez pas les fonctionnalités d’évaluation sur les abonnements de production.Don't enable preview features on production subscriptions. Utilisez un abonnement distinct pour tester les fonctionnalités d’évaluation et recueillir des commentaires.Use a separate subscription to test preview features and gather feedback.

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

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).It takes a few minutes for the status to show Registered. Vous pouvez vérifier l’état de l’enregistrement à l’aide de la commande az feature list :You can check on the registration status using the az feature list command:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"

Lorsque vous êtes prêt, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register :When ready, refresh the registration of the Microsoft.ContainerService resource provider using the az provider register command:

az provider register --namespace Microsoft.ContainerService

Présentation des stratégies de sécurité des podsOverview of pod security policies

Dans un cluster Kubernetes, un contrôleur d’admission est utilisé pour intercepter les requêtes envoyées au serveur d’API lorsqu’une ressource doit être créée.In a Kubernetes cluster, an admission controller is used to intercept requests to the API server when a resource is to be created. 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.The admission controller can then validate the resource request against a set of rules, or mutate the resource to change deployment parameters.

PodSecurityPolicy est un contrôleur d’admission qui confirme si une spécification de pod répond à vos besoins définis.PodSecurityPolicy is an admission controller that validates a pod specification meets your defined requirements. 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.These requirements may limit the use of privileged containers, access to certain types of storage, or the user or group the container can run as. 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.When you try to deploy a resource where the pod specifications don't meet the requirements outlined in the pod security policy, the request is denied. 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.This ability to control what pods can be scheduled in the AKS cluster prevents some possible security vulnerabilities or privilege escalations.

Lorsque vous activez la stratégie de sécurité des pods dans un cluster AKS, certaines stratégies par défaut sont appliquées.When you enable pod security policy in an AKS cluster, some default policies are applied. Ces stratégies par défaut fournissent une expérience prête à l’emploi pour définir les pods à planifier.These default policies provide an out-of-the-box experience to define what pods can be scheduled. Toutefois, les utilisateurs de cluster peuvent rencontrer des problèmes de déploiement de pods jusqu'à ce que vous définissez vos propres stratégies.However, cluster users may run into problems deploying pods until you define your own policies. L'approche recommandée consiste à :The recommended approach is to:

  • Créer un cluster AKSCreate an AKS cluster
  • Définir vos propres stratégies de sécurité des podsDefine your own pod security policies
  • Activer la fonctionnalité de stratégie de sécurité des podsEnable the pod security policy feature

Pour montrer comment les stratégies par défaut limitent les déploiements de pods, dans cet article, nous allons tout d’abord activer la fonctionnalité de stratégies de sécurité des pods, puis créer une stratégie personnalisée.To show how the default policies limit pod deployments, in this article we first enable the pod security policies feature, then create a custom policy.

Activer la stratégie de sécurité des pods sur un cluster AKSEnable pod security policy on an AKS cluster

Vous pouvez activer ou désactiver la stratégie de sécurité des pods à l’aide de la commande az aks update.You can enable or disable pod security policy using the az aks update command. L’exemple suivant active la stratégie de sécurité des pods sur le nom de cluster myAKSCluster dans le groupe de ressources nommé myResourceGroup.The following example enables pod security policy on the cluster name myAKSCluster in the resource group named myResourceGroup.

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.For real-world use, don't enable the pod security policy until you have defined your own custom policies. Dans cet article, vous activez 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.In this article, you enable pod security policy as the first step to see how the default policies limit pod deployments.

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

Stratégies AKS par défautDefault AKS policies

Lorsque vous activez la stratégie de sécurité des pods, AKS crée une seule stratégie par défaut nommée privileged.When you enable pod security policy, AKS creates one default policy named privileged. Ne modifiez pas et ne supprimez pas cette stratégie par défaut.Don't edit or remove the default policy. Créez plutôt vos propres stratégies qui définissent les paramètres souhaités pour le contrôle.Instead, create your own policies that define the settings you want to control. Nous allons examiner ces stratégies par défaut et observer leur impact sur les déploiements de pods.Let's first look at what these default policies are how they impact pod deployments.

Pour afficher les stratégies disponibles, utilisez la commande kubectl get psp, comme indiqué dans l’exemple suivantTo view the policies available, use the kubectl get psp command, as shown in the following example

$ kubectl get psp

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.The privileged pod security policy is applied to any authenticated user in the AKS cluster. Cette affectation est contrôlée par ClusterRoles et ClusterRoleBindings.This assignment is controlled by ClusterRoles and ClusterRoleBindings. Utilisez la commande kubectl get clusterrolebindings et recherchez la liaison default:priviledged :Use the kubectl get clusterrolebindings command and search for the default:priviledged: binding:

kubectl get clusterrolebindings default:priviledged -o yaml

Comme indiqué dans la sortie condensée suivante, le ClusterRole psp:restricted est attribué à tous les utilisateurs system:authenticated.As shown in the following condensed output, the psp:restricted ClusterRole is assigned to any system:authenticated users. Cette capacité offre un niveau de base pour les restrictions sans avoir à définir vos propres stratégies.This ability provides a basic level of restrictions without your own policies being defined.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  [...]
  name: default:priviledged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:priviledged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

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.It's important to understand how these default policies interact with user requests to schedule pods before you start to create your own pod security policies. Dans les sections suivantes, nous allons planifier des pods pour voir ces stratégies par défaut en action.In the next few sections, let's schedule some pods to see these default policies in action.

Créer un utilisateur de test dans un cluster AKSCreate a test user in an AKS cluster

Par défaut, lorsque vous utilisez la commande az aks get-credentials, les informations d'identification administrateur du cluster AKS sont ajoutées à votre configuration kubectl. L’utilisateur administrateur ignore la mise en œuvre des stratégies de sécurité des pods.By default, when you use the az aks get-credentials command, the admin credentials for the AKS cluster are added to your kubectl config. The admin user bypasses the enforcement of pod security policies. Si vous utilisez l’intégration Azure Active Directory pour vos clusters AKS, vous pouvez vous connecter avec les informations d’identification d’un utilisateur non administrateur pour voir la mise en œuvre des stratégies en action.If you use Azure Active Directory integration for your AKS clusters, you could sign in with the credentials of a non-admin user to see the enforcement of policies in action. Dans cet article, nous allons créer un compte d’utilisateur de test dans le cluster AKS que vous pouvez utiliser.In this article, let's create a test user account in the AKS cluster that you can use.

Créer un espace de noms exemple nommé psp-aks pour les ressources de test à l’aide de la commande kubectl create namespace.Create a sample namespace named psp-aks for test resources using the kubectl create namespace command. Ensuite, créez un compte de service nommé nonadmin-user à l’aide de la commande kubectl create serviceaccount :Then, create a service account named nonadmin-user using the kubectl create serviceaccount command:

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

Créez un RoleBinding pour nonadmin-user afin d’effectuer des actions de base dans l’espace de noms à l’aide de la commande  kubectl create rolebinding :Next, create a RoleBinding for the nonadmin-user to perform basic actions in the namespace using the kubectl create rolebinding command:

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-administrateurCreate alias commands for admin and non-admin user

Pour mettre en évidence la différence entre l’utilisateur administrateur régulier lors de l’utilisation de kubectl et l’utilisateur non administrateur créé lors des étapes précédentes, créez deux alias de ligne de commande :To highlight the difference between the regular admin user when using kubectl and the non-admin user created in the previous steps, create two command-line aliases:

  • L’alias kubectl-admin est destiné à l’utilisateur administrateur régulier et limité à l’espace de noms psp-aks.The kubectl-admin alias is for the regular admin user, and is scoped to the psp-aks namespace.
  • L’alias kubectl-nonadminuser est destiné à nonadmin-user créé à l’étape précédente et limité à l’espace de noms psp-aks.The kubectl-nonadminuser alias is for the nonadmin-user created in the previous step, and is scoped to the psp-aks namespace.

Créez ces deux alias comme indiqué dans les commandes suivantes :Create these two aliases as shown in the following commands:

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éTest the creation of a privileged pod

Nous allons commencer par tester ce qui se passe lorsque vous planifiez un pod avec le contexte de sécurité privileged: true.Let's first test what happens when you schedule a pod with the security context of privileged: true. Ce contexte de sécurité fait remonter les privilèges du pod.This security context escalates the pod's privileges. Dans la section précédente qui montrait les stratégies de sécurité des pods par défaut d’AKS, la stratégie restricted devait refuser cette requête.In the previous section that showed the default AKS pod security policies, the restricted policy should deny this request.

Créez un fichier nommé nginx-privileged.yaml et collez le manifeste YAML suivant :Create a file named nginx-privileged.yaml and paste the following YAML manifest:

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

Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create the pod using the kubectl apply command and specify the name of your YAML manifest:

kubectl-nonadminuser apply -f nginx-privileged.yaml

La planification de la commande échoue, comme indiqué dans l’exemple de sortie suivant :The pod fails to be scheduled, as shown in the following example output:

$ kubectl-nonadminuser apply -f nginx-privileged.yaml

Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

Le pod n'atteint pas la phase de planification ; il n'existe aucune ressource à supprimer avant de poursuivre.The pod doesn't reach the scheduling stage, so there are no resources to delete before you move on.

Tester la création d’un pod non privilégiéTest creation of an unprivileged pod

Dans l’exemple précédent, la spécification de pod a demandé une élévation des privilèges.In the previous example, the pod specification requested privileged escalation. Cette requête est refusée par la stratégie de sécurité des pods restricted par défaut. Il est donc impossible de planifier le pod.This request is denied by the default restricted pod security policy, so the pod fails to be scheduled. Essayons maintenant d’exécuter ce même pod NGINX sans la requête d’élévation des privilèges.Let's try now running that same NGINX pod without the privilege escalation request.

Créez un fichier nommé nginx-unprivileged.yaml et collez le manifeste YAML suivant :Create a file named nginx-unprivileged.yaml and paste the following YAML manifest:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: nginx:1.14.2

Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create the pod using the kubectl apply command and specify the name of your YAML manifest:

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

Le planificateur Kubernetes accepte la requête du pod.The Kubernetes scheduler accepts the pod request. Toutefois, si vous examinez l’état du pod en utilisant kubectl get pods, il existe une erreur :However, if you look at the status of the pod using kubectl get pods, there's an error:

$ kubectl-nonadminuser get pods

NAME                 READY   STATUS                       RESTARTS   AGE
nginx-unprivileged   0/1     CreateContainerConfigError   0          26s

Utilisez la commande kubectl describe pod pour examiner les événements du pod.Use the kubectl describe pod command to look at the events for the pod. L’exemple condensé suivant montre que le conteneur et l’image nécessitent des autorisations à la racine, même si nous ne les avez pas demandées :The following condensed example shows the container and image require root permissions, even though we didn't request them:

$ kubectl-nonadminuser describe pod nginx-unprivileged

Name:               nginx-unprivileged
Namespace:          psp-aks
Priority:           0
PriorityClassName:  <none>
Node:               aks-agentpool-34777077-0/10.240.0.4
Start Time:         Thu, 28 Mar 2019 22:05:04 +0000
[...]
Events:
  Type     Reason     Age                     From                               Message
  ----     ------     ----                    ----                               -------
  Normal   Scheduled  7m14s                   default-scheduler                  Successfully assigned psp-aks/nginx-unprivileged to aks-agentpool-34777077-0
  Warning  Failed     5m2s (x12 over 7m13s)   kubelet, aks-agentpool-34777077-0  Error: container has runAsNonRoot and image will run as root
  Normal   Pulled     2m10s (x25 over 7m13s)  kubelet, aks-agentpool-34777077-0  Container image "nginx:1.14.2" already present on machine

Même si nous n’avez pas demandé un accès privilégié, l’image de conteneur pour NGINX a besoin de créer une liaison sur le port 80.Even though we didn't request any privileged access, the container image for NGINX needs to create a binding for port 80. Pour lier les ports 1024 et suivants, l’utilisateur racine est requis.To bind ports 1024 and below, the root user is required. Lorsque le pod essaie de démarrer, la stratégie de sécurité des pods restricted refuse cette requête.When the pod tries to start, the restricted pod security policy denies this request.

Cet exemple montre que les stratégies de sécurité des pods par défaut créées par AKS sont en vigueur et limitent les actions qu’un utilisateur peut effectuer.This example shows that the default pod security policies created by AKS are in effect and restrict the actions a user can perform. Il est important de comprendre le comportement de ces stratégies par défaut, car le refus d’un pod NGINX de base peut vous surprendre.It's important to understand the behavior of these default policies, as you may not expect a basic NGINX pod to be denied.

Avant de passer à l’étape suivante, supprimez ce pod de test à l’aide de la commande kubectl delete pod :Before you move on to the next step, delete this test pod using the kubectl delete pod command:

kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Tester la création d’un pod avec un contexte utilisateur spécifiqueTest creation of a pod with a specific user context

Dans l’exemple précédent, l’image de conteneur tentait automatiquement d’utiliser la racine pour lier NGINX au port 80.In the previous example, the container image automatically tried to use root to bind NGINX to port 80. Cette requête était refusée par la stratégie de sécurité des pods restricted par défaut. Il était donc impossible de planifier le pod.This request was denied by the default restricted pod security policy, so the pod fails to start. Nous allons essayer maintenant d’exécuter ce même pod NGINX avec un contexte utilisateur spécifique, tel que runAsUser: 2000.Let's try now running that same NGINX pod with a specific user context, such as runAsUser: 2000.

Créez un fichier nommé nginx-unprivileged-nonroot.yaml et collez le manifeste YAML suivant :Create a file named nginx-unprivileged-nonroot.yaml and paste the following YAML manifest:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: nginx:1.14.2
      securityContext:
        runAsUser: 2000

Créez le pod à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create the pod using the kubectl apply command and specify the name of your YAML manifest:

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

Le planificateur Kubernetes accepte la requête du pod.The Kubernetes scheduler accepts the pod request. Toutefois, si vous examinez l’état du pod avec kubectl get pods, il existe une erreur différente de l’exemple précédent :However, if you look at the status of the pod using kubectl get pods, there's a different error than the previous example:

$ kubectl-nonadminuser get pods

NAME                         READY   STATUS              RESTARTS   AGE
nginx-unprivileged-nonroot   0/1     CrashLoopBackOff    1          3s

Utilisez la commande kubectl describe pod pour examiner les événements du pod.Use the kubectl describe pod command to look at the events for the pod. L’exemple condensé suivant montre les événements de pod :The following condensed example shows the pod events:

$ kubectl-nonadminuser describe pods nginx-unprivileged

Name:               nginx-unprivileged
Namespace:          psp-aks
Priority:           0
PriorityClassName:  <none>
Node:               aks-agentpool-34777077-0/10.240.0.4
Start Time:         Thu, 28 Mar 2019 22:05:04 +0000
[...]
Events:
  Type     Reason     Age                   From                               Message
  ----     ------     ----                  ----                               -------
  Normal   Scheduled  2m14s                 default-scheduler                  Successfully assigned psp-aks/nginx-unprivileged-nonroot to aks-agentpool-34777077-0
  Normal   Pulled     118s (x3 over 2m13s)  kubelet, aks-agentpool-34777077-0  Container image "nginx:1.14.2" already present on machine
  Normal   Created    118s (x3 over 2m13s)  kubelet, aks-agentpool-34777077-0  Created container
  Normal   Started    118s (x3 over 2m12s)  kubelet, aks-agentpool-34777077-0  Started container
  Warning  BackOff    105s (x5 over 2m11s)  kubelet, aks-agentpool-34777077-0  Back-off restarting failed container

Les événements indiquent que le conteneur a été créé et démarré.The events indicate that the container was created and started. Il n’y a aucune raison évidente à l’échec du pod.There's nothing immediately obvious as to why the pod is in a failed state. Examinons les journaux du pod à l’aide de la commande kubectl logs :Let's look at the pod logs using the kubectl logs command:

kubectl-nonadminuser logs nginx-unprivileged-nonroot --previous

L’exemple de sortie de journal suivant indique que, dans la configuration NGINX elle-même, il existe une erreur d’autorisations lorsque le service essaie de démarrer.The following example log output gives an indication that within the NGINX configuration itself, there's a permissions error when the service tries to start. Cette erreur est due de nouveau au besoin de liaison sur le port 80.This error is again caused by needing to bind to port 80. Bien que la spécification de pod a défini un compte d’utilisateur régulier, ce compte d’utilisateur n’est pas suffisant au niveau du système d’exploitation du service NGINX pour démarrer et établir la liaison au port restreint.Although the pod specification defined a regular user account, this user account isn't sufficient in the OS-level for the NGINX service to start and bind to the restricted port.

$ kubectl-nonadminuser logs nginx-unprivileged-nonroot --previous

2019/03/28 22:38:29 [warn] 1#1: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2019/03/28 22:38:29 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

Là encore, il est important de comprendre le comportement des stratégies de sécurité des pods par défaut.Again, it's important to understand the behavior of the default pod security policies. Cette erreur était un peu plus difficile à repérer et, à nouveau, le refus d’un pod NGINX de base peut vous surprendre.This error was a little harder to track down, and again, you may not expect a basic NGINX pod to be denied.

Avant de passer à l’étape suivante, supprimez ce pod de test à l’aide de la commande kubectl delete pod :Before you move on to the next step, delete this test pod using the kubectl delete pod command:

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

Créer une stratégie de sécurité des pods personnaliséeCreate a custom pod security policy

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.Now that you've seen the behavior of the default pod security policies, let's provide a way for the nonadmin-user to successfully schedule pods.

Nous allons créer une stratégie pour rejeter les pods qui demandent un accès privilégié.Let's create a policy to reject pods that request privileged access. Les autres options, telles que runAsUser ou les volumes autorisés, ne sont pas explicitement limitées.Other options, such as runAsUser or allowed volumes, aren't explicitly restricted. Ce type de stratégie refuse une requête d’accès privilégié, mais elle permet néanmoins au cluster d’exécuter les pods demandés.This type of policy denies a request for privileged access, but otherwise lets the cluster run the requested pods.

Créez un fichier nommé psp-deny-privileged.yaml et collez le manifeste YAML suivant :Create a file named psp-deny-privileged.yaml and paste the following YAML manifest:

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:
  - '*'

Créez la stratégie à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create the policy using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f psp-deny-privileged.yaml

Pour afficher les stratégies disponibles, utilisez la commande kubectl get psp, comme indiqué dans l’exemple suivant.To view the policies available, use the kubectl get psp command, as shown in the following example. Comparez la stratégie psp-deny-privileged à la stratégie restricted par défaut appliquée dans les exemples précédents de création de pod.Compare the psp-deny-privileged policy with the default restricted policy that was enforced in the previous examples to create a pod. Seule l’utilisation de l’escalade PRIV est refusée par votre stratégie.Only the use of PRIV escalation is denied by your policy. Il n’existe aucune restriction sur l’utilisateur ou le groupe pour la stratégie psp-deny-privileged.There are no restrictions on the user or group for the psp-deny-privileged policy.

$ kubectl get psp

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            *          configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

Autoriser le compte d’utilisateur à utiliser la stratégie de sécurité des pods personnaliséeAllow user account to use the custom pod security policy

À 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é.In the previous step, you created a pod security policy to reject pods that request privileged access. Pour permettre l’utilisation de la stratégie, vous créez un rôle ou un ClusterRole.To allow the policy to be used, you create a Role or a ClusterRole. Ensuite, vous associez un de ces rôles à l’aide de RoleBinding ou ClusterRoleBinding.Then, you associate one of these roles using a RoleBinding or ClusterRoleBinding.

Pour cet exemple, créez un ClusterRole qui vous permet d’utiliser la stratégie psp-deny-privileged créée à l’étape précédente.For this example, create a ClusterRole that allows you to use the psp-deny-privileged policy created in the previous step. Créez un fichier nommé psp-deny-privileged-clusterrole.yaml et collez le manifeste YAML suivant :Create a file named psp-deny-privileged-clusterrole.yaml and paste the following YAML manifest:

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

Créez le ClusterRole à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create the ClusterRole using the kubectl apply command and specify the name of your YAML manifest:

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

Créez maintenant un ClusterRoleBinding pour utiliser le ClusterRole créé à l’étape précédente.Now create a ClusterRoleBinding to use the ClusterRole created in the previous step. Créez un fichier nommé psp-deny-privileged-clusterrolebinding.yaml et collez le manifeste YAML suivant :Create a file named psp-deny-privileged-clusterrolebinding.yaml and paste the following YAML manifest:

apiVersion: rbac.authorization.k8s.io/v1beta1
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

Créez un ClusterRoleBinding à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :Create a ClusterRoleBinding using the kubectl apply command and specify the name of your YAML manifest:

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.In the first step of this article, the pod security policy feature was enabled on the AKS cluster. 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.The recommended practice was to only enable the pod security policy feature after you've defined your own policies. Il s’agit du stade où vous devez activer la fonctionnalité de stratégie de sécurité des pods.This is the stage where you would enable the pod security policy feature. Au moins une stratégie personnalisée a été définie, et les comptes d’utilisateur ont été associés à ces stratégies.One or more custom policies have been defined, and user accounts have been associated with those policies. Désormais, vous pouvez 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.Now you can safely enable the pod security policy feature and minimize problems caused by the default policies.

Retester la création d’un pod non privilégiéTest the creation of an unprivileged pod again

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é.With your custom pod security policy applied and a binding for the user account to use the policy, let's try to create an unprivileged pod again. Utilisez le même manifeste nginx-privileged.yaml pour créer le pod à l’aide de la commande kubectl apply :Use the same nginx-privileged.yaml manifest to create the pod using the kubectl apply command:

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

Le pod est planifié avec succès.The pod is successfully scheduled. Lorsque vous vérifiez l’état du pod à l’aide de la commande kubectl get pods, le pod est en cours d’exécution :When you check the status of the pod using the kubectl get pods command, the pod is Running:

$ kubectl-nonadminuser get pods

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

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.This example shows how you can create custom pod security policies to define access to the AKS cluster for different users or groups. 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.The default AKS policies provide tight controls on what pods can run, so create your own custom policies to then correctly define the restrictions you need.

Supprimez le pod non privilégié NGINX à l’aide de la commande kubectl delete et spécifiez le nom de votre manifeste YAML :Delete the NGINX unprivileged pod using the kubectl delete command and specify the name of your YAML manifest:

kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Supprimer des ressourcesClean up resources

Pour désactiver la stratégie de sécurité des pods, utilisez la commande az aks update à nouveau.To disable pod security policy, use the az aks update command again. L’exemple suivant désactive la stratégie de sécurité des pods sur le nom de cluster myAKSCluster dans le groupe de ressources nommé myResourceGroup :The following example disables pod security policy on the cluster name myAKSCluster in the resource group named myResourceGroup:

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

Ensuite, supprimez ClusterRole et ClusterRoleBinding :Next, delete the ClusterRole and ClusterRoleBinding:

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

Supprimez la stratégie réseau à l’aide de la commande kubectl delete et précisez le nom de votre manifeste YAML :Delete the network policy using kubectl delete command and specify the name of your YAML manifest:

kubectl delete -f psp-deny-privileged.yaml

Enfin, supprimez l’espace de noms psp-aks :Finally, delete the psp-aks namespace:

kubectl delete namespace psp-aks

Étapes suivantesNext steps

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é.This article showed you how to create a pod security policy to prevent the use of privileged access. Il existe un grand nombre de fonctionnalités qu’une stratégie peut appliquer, comme le type de volume ou l’utilisateur RunAs.There are lots of features that a policy can enforce, such as type of volume or the RunAs user. 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.For more information on the available options, see the Kubernetes pod security policy reference docs.

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.For more information about limiting pod network traffic, see Secure traffic between pods using network policies in AKS.