Aller au contenu

Bank 4 – Mise en ordre (Partie 2 : Configuration / Sécurité)

Instructions

Remettez les étapes dans le bon ordre chronologique ou logique.
Cliquez sur « Correction » pour vérifier.

Total : 10 exercices (2 faciles · 4 moyens · 4 difficiles)

Niveau Facile

Exercice 1 : La création et l'utilisation d'un ConfigMap en variable d'environnement

Consigne : Remettez dans l'ordre les étapes pour externaliser une configuration textuelle et l'injecter dans un conteneur.

  • [A] Rédiger le manifeste YAML d'un ConfigMap contenant les paires clé-valeur de configuration.
  • [B] Déclarer dans le manifeste du Pod l'injection des variables d'environnement en ciblant le ConfigMap via envFrom ou configMapRef.
  • [C] Appliquer le ConfigMap sur le cluster avec la commande kubectl apply -f configmap.yaml.
  • [D] Déployer le pod et vérifier que l'application lit correctement ses variables d'environnement.
Correction

A → C → B → D
On crée le contenu du ConfigMap, on l'applique sur le cluster, on configure le pod pour qu'il s'y réfère, puis on déploie l'ensemble.

Exercice 2 : La création d'un Secret Kubernetes par ligne de commande

Consigne : Ordonnez les étapes pour générer rapidement un secret textuel et l'utiliser.

  • [A] Vérifier la création de l'objet avec kubectl get secrets et observer son encodage par défaut.
  • [B] Créer le secret de manière impérative via la ligne de commande kubectl create secret generic mon-secret --from-literal=cle=valeur.
  • [C] Configurer un volume ou une variable d'environnement dans le manifeste d'un pod pour consommer ce secret.
  • [D] Déployer le pod pour que l'application puisse exploiter la donnée sensible.
Correction

B → A → C → D
On génère le secret en ligne de commande, on vérifie son existence, on prépare le pod pour l'y intégrer, et on déploie.

Niveau Moyen

Exercice 3 : Le traitement d'une requête d'autorisation RBAC

Consigne : Remettez dans l'ordre les étapes de vérification des droits d'accès d'un utilisateur par l'API Server.

  • [A] L'API Server consulte les liaisons de rôles (RoleBinding ou ClusterRoleBinding) associées à l'utilisateur ou à son groupe.
  • [B] L'utilisateur soumet une requête (ex: supprimer un pod) accompagnée de ses informations d'authentification.
  • [C] Le système vérifie si les permissions accordées par le rôle lié autorisent explicitement l'action demandée sur la ressource ciblée.
  • [D] L'API Server autorise l'exécution de la requête ou retourne un code d'erreur 403 Forbidden.
Correction

B → A → C → D
La requête arrive avec l'identité, le système cherche les liaisons de rôles correspondantes, évalue les verbes et ressources autorisés, puis statue sur la permission.

Exercice 4 : La mise en place et l'évaluation d'une NetworkPolicy restrictive

Consigne : Ordonnez les étapes de mise en place d'une isolation réseau par politique.

  • [A] Le plugin CNI du cluster analyse la NetworkPolicy et traduit la déclaration en règles de filtrage bas niveau (ex: iptables ou programmes eBPF).
  • [B] L'administrateur crée un fichier YAML de NetworkPolicy ciblant des pods spécifiques via un podSelector et définissant les règles d'accès ingress/egress.
  • [C] Un pod non autorisé tente d'envoyer un flux réseau vers un pod protégé, et le paquet est immédiatement rejeté au niveau du noyau.
  • [D] Le fichier de politique réseau est appliqué sur le cluster via kubectl apply -f network-policy.yaml.
Correction

B → D → A → C
On rédige la politique, on l'applique, le CNI l'implémente dans le noyau de la machine, et la règle commence à filtrer les paquets non conformes.

Exercice 5 : Le montage d'un volume basé sur un Secret en mémoire RAM

Consigne : Remettez dans l'ordre les étapes d'utilisation sécurisée d'un secret sous forme de fichier.

  • [A] Le kubelet récupère le Secret depuis l'API Server lors de l'instanciation du pod.
  • [B] Le kubelet monte le secret dans un système de fichiers virtuel en mémoire vive (tmpfs) sur le nœud.
  • [C] Le conteneur démarre et accède aux données du secret sous forme de fichiers dans le répertoire monté (via volumeMounts).
  • [D] L'administrateur spécifie un volume de type secret dans la section volumes du manifeste du Pod.
Correction

D → A → B → C
On déclare le volume secret dans le manifeste, le kubelet le récupère et le monte en RAM (tmpfs), puis le conteneur y accède en lecture locale.

Exercice 6 : L'audit des autorisations d'un compte avec kubectl auth can-i

Consigne : Ordonnez les étapes d'un audit rapide des droits d'un administrateur ou d'un service account.

  • [A] L'outil analyse les liaisons de rôles et les règles RBAC effectives pour le contexte courant.
  • [B] L'opérateur exécute la commande de diagnostic kubectl auth can-i create deployments --namespace=production.
  • [C] L'API Server évalue l'ensemble des règles applicables à l'utilisateur actif.
  • [D] L'outil retourne un résultat booléen clair (yes ou no) indiquant si l'action est permise.
Correction

B → C → A → D
L'opérateur lance la commande d'audit, l'API interroge les règles RBAC et liaisons associées, et retourne la réponse binaire finale.

Niveau Difficile

Exercice 7 : La migration et la rétroactivité du chiffrement au repos (EncryptionConfiguration)

Consigne : Remettez dans l'ordre chronologique les étapes pour sécuriser des secrets existants dans la base de données.

  • [A] L'administrateur active le fichier de configuration de chiffrement (EncryptionConfiguration) sur le plan de contrôle de k3s/Kubernetes.
  • [B] Les nouveaux secrets créés après la modification sont désormais chiffrés automatiquement à l'écriture dans la base de données.
  • [C] L'administrateur force la réécriture de l'ensemble des secrets préexistants non chiffrés (ex: kubectl get secrets --all-namespaces -o json | kubectl replace -f -).
  • [D] Le stockage backend contient désormais l'intégralité des secrets protégés par le mécanisme de chiffrement actif.
Correction

A → B → C → D
On active la configuration (seuls les nouveaux secrets sont pris en compte), puis on procède à une réécriture globale de l'existant pour appliquer le chiffrement rétroactivement à tout le contenu.

Exercice 8 : L'application d'un durcissement de conteneur (SecurityContext et capacités Linux)

Consigne : Ordonnez les étapes de validation et d'exécution d'un conteneur durci contre les élévations de privilèges.

  • [A] Le kubelet analyse le bloc securityContext du manifeste du Pod (ex: runAsNonRoot: true, capabilities.drop: ["ALL"]).
  • [B] Le conteneur est lancé par le runtime avec un utilisateur non-root et un ensemble de privilèges Linux minimaliste.
  • [C] Si le conteneur tente de s'exécuter en tant qu'utilisateur root (UID 0), le kubelet rejette immédiatement le démarrage et lève une erreur.
  • [D] Le fichier manifeste est validé par l'API Server et transmis au nœud worker assigné.
Correction

D → A → C → B
Le manifeste arrive sur le nœud, le kubelet évalue les règles de sécurité, bloque le démarrage si le conteneur est en root, ou l'exécute avec les restrictions de capacités demandées.

Exercice 9 : La gestion d'une violation de NetworkPolicy par le noyau Linux

Consigne : Remettez dans l'ordre les événements techniques lorsqu'un trafic non autorisé atteint un pod protégé.

  • [A] Le paquet réseau arrive sur l'interface réseau virtuelle du nœud destination.
  • [B] Le sous-système de filtrage du noyau (ex: tables iptables ou programmes eBPF configurés par le CNI) intercepte le paquet.
  • [C] Le système compare la source du paquet avec les sélecteurs autorisés par la NetworkPolicy active.
  • [D] Ne trouvant aucune correspondance d'autorisation, le noyau rejette ou supprime silencieusement le paquet (DROP).
Correction

A → B → C → D
Le paquet physique/virtuel atteint le nœud, le noyau l'intercepte via les règles CNI, évalue les conditions de la NetworkPolicy, et applique le rejet si non autorisé.

Exercice 10 : La résolution d'une alerte de sécurité liée à l'utilisation d'un secret en GitOps

Consigne : Ordonnez les étapes d'un correctif de sécurité pour un secret stocké par erreur en clair/Base64 dans un dépôt Git.

  • [A] L'équipe de développement chiffre le secret à l'aide d'un outil adapté (comme SOPS ou Sealed Secrets) pour obtenir un fichier manifeste sécurisé.
  • [B] L'ancien secret non sécurisé est révoqué et supprimé du cluster et de l'historique du dépôt Git.
  • [C] Le nouveau manifeste chiffré est poussé sur le dépôt Git et déployé proprement par l'agent GitOps sur le cluster.
  • [D] L'analyse de code ou l'audit de sécurité détecte la présence d'un secret encodé en Base64 brut dans le dépôt public.
Correction

D → B → A → C
On repère l'anomalie de sécurité, on nettoie le passé (révocation/suppression), on chiffre correctement le secret, et on déploie la version sécurisée via le pipeline GitOps.