Bank 3 – Appariement (Partie 2 : Configuration / Sécurité)¶
Instructions
Reliez chaque élément de la Colonne A à sa correspondance dans la Colonne B.
Cliquez sur « Correction » pour vérifier vos réponses.
Total : 10 exercices (2 faciles · 4 moyens · 4 difficiles)
Niveau Facile¶
Exercice 1 : Objets de configuration et d'identité¶
Consigne : Reliez chaque ressource de configuration ou de sécurité à son rôle principal.
| Colonne A (Ressource) | Colonne B (Rôle principal) |
|---|---|
| 1. ConfigMap | A. Stocke des données sensibles (mots de passe, tokens) encodées par défaut en Base64. |
| 2. Secret | B. Fournit une identité aux processus s'exécutant dans les pods pour s'authentifier auprès de l'API. |
| 3. ServiceAccount | C. Stocke des paires clé-valeur de configuration non sensibles en texte clair. |
| 4. NetworkPolicy | D. Contrôle l'isolation et le filtrage du trafic réseau entre les pods (pare-feu). |
Correction
1-C, 2-A, 3-B, 4-D
Exercice 2 : Fondamentaux de la sécurité Kubernetes¶
Consigne : Associez le terme de sécurité à sa définition de base.
| Colonne A (Terme) | Colonne B (Définition) |
|---|---|
| 1. Encodage Base64 | A. Modèle de contrôle d'accès basé sur les rôles pour réglementer les permissions. |
| 2. RBAC | B. Format de représentation de données textuelles réversibles, non sécurisé contre le déchiffrement. |
| 3. Namespace | C. Compte utilisateur privilégié (UID 0) qu'il est recommandé d'éviter dans les conteneurs. |
| 4. Root | D. Frontière logique permettant d'isoler des ressources au sein d'un même cluster. |
Correction
1-B, 2-A, 3-D, 4-C
Niveau Moyen¶
Exercice 3 : Méthodes d'injection de configuration¶
Consigne : Reliez la méthode d'injection à sa modalité technique.
| Colonne A (Méthode) | Colonne B (Modalité technique) |
|---|---|
1. envFrom avec configMapRef |
A. Monte les clés du ConfigMap ou Secret sous forme de fichiers dans un répertoire du conteneur. |
2. volumes et volumeMounts |
B. Injecte l'ensemble des clés d'un ConfigMap sous forme de variables d'environnement d'un coup. |
3. env avec valueFrom |
C. Injecte une seule clé spécifique d'un ConfigMap ou Secret dans une variable d'environnement ciblée. |
Correction
1-B, 2-A, 3-C
Exercice 4 : Objets RBAC¶
Consigne : Associez l'objet RBAC à sa portée ou sa fonction.
| Colonne A (Objet RBAC) | Colonne B (Portée / Fonction) |
|---|---|
| 1. Role | A. Objet appliquant des autorisations globales à l'échelle de tout le cluster. |
| 2. ClusterRole | B. Objet définissant des permissions (règles de lecture/écriture) limitées à un namespace spécifique. |
| 3. RoleBinding | C. Lie un Role ou ClusterRole à un sujet (utilisateur/service account) à l'échelle globale du cluster. |
| 4. ClusterRoleBinding | D. Lie des permissions à un sujet au sein d'un namespace spécifique. |
Correction
1-B, 2-A, 3-D, 4-C
Exercice 5 : Sécurité des conteneurs (SecurityContext)¶
Consigne : Reliez le paramètre de sécurité au niveau du pod/conteneur à son effet.
| Colonne A (Paramètre) | Colonne B (Effet de sécurité) |
|---|---|
1. runAsNonRoot: true |
A. Empêche le conteneur d'écrire sur son système de fichiers racine pour garantir l'immuabilité. |
2. readOnlyRootFilesystem: true |
B. Interdit au conteneur de démarrer s'il s'exécute en tant qu'utilisateur root (UID 0). |
3. allowPrivilegeEscalation: false |
C. Empêche un processus de s'élever à des privilèges supérieurs à ceux de son parent. |
Correction
1-B, 2-A, 3-C
Exercice 6 : Commandes kubectl pour la sécurité¶
Consigne : Associez la commande de diagnostic ou de création sécurisée à son objectif.
| Colonne A (Commande) | Colonne B (Objectif) |
|---|---|
1. kubectl auth can-i |
A. Crée rapidement un Secret générique à partir de valeurs textuelles directes en ligne de commande. |
2. kubectl create secret generic |
B. Vérifie si l'utilisateur courant possède les autorisations RBAC pour effectuer une action. |
3. kubectl create configmap |
C. Génère un objet de configuration non sensible directement à partir de fichiers ou de littéraux. |
Correction
1-B, 2-A, 3-C
Niveau Difficile¶
Exercice 7 : Règles avancées de NetworkPolicy¶
Consigne : Reliez le sélecteur de NetworkPolicy à sa portée de filtrage.
| Colonne A (Sélecteur / Section) | Colonne B (Conséquence / Portée du filtrage) |
|---|---|
1. podSelector: {} |
A. Filtre le trafic entrant (ingress) en provenance d'un espace de noms entier spécifique. |
2. namespaceSelector |
B. Sélectionne l'ensemble des pods du namespace courant où la politique est appliquée. |
3. policyTypes: [Ingress] avec liste vide |
C. Active le mode "Default Deny Ingress" total : bloque tout le trafic entrant non autorisé. |
4. egress |
D. Contrôle et filtre spécifiquement les flux réseau sortants des pods ciblés. |
Correction
1-B, 2-A, 3-C, 4-D
Exercice 8 : Chiffrement, Stockage et Secrets¶
Consigne : Reliez le concept de protection des données sensibles à sa réalité technique.
| Colonne A (Concept) | Colonne B (Réalité technique) |
|---|---|
1. Volume de type tmpfs |
A. Outil tiers permettant de chiffrer les secrets dans les manifestes GitOps (via des clés publiques/privées). |
2. EncryptionConfiguration |
B. Stocke les secrets montés en RAM sur le nœud worker pour éviter l'écriture sur disque physique. |
| 3. Outil SOPS / Sealed Secrets | C. Active le chiffrement au repos (ex. AES-CBC) dans la base de données backend de Kubernetes. |
| 4. Réécriture des secrets post-chiffrement | D. Action obligatoire pour chiffrer rétroactivement les secrets créés avant l'activation d'EncryptionConfiguration. |
Correction
1-B, 2-C, 3-A, 4-D
Exercice 9 : Comportements de sécurité et pièges¶
Consigne : Associez la situation de sécurité au comportement effectif du système.
| Colonne A (Situation) | Colonne B (Comportement effectif du système) |
|---|---|
| 1. Absence de CNI supportant les NetworkPolicies | A. Les variables d'environnement restent inchangées ; un redémarrage du pod est obligatoire. |
| 2. Modification d'un ConfigMap injecté en variable d'env | B. Les manifestes NetworkPolicy sont enregistrés dans l'API mais totalement ignorés. |
3. Utilisation de verbes get et list sur les Secrets |
C. Permet de récupérer le manifeste complet et de décoder immédiatement le Base64. |
Correction
1-B, 2-A, 3-C
Exercice 10 : Privilèges Linux et Capacités (Capabilities)¶
Consigne : Reliez la directive de durcissement Linux au niveau du conteneur à son effet.
| Colonne A (Directive de durcissement) | Colonne B (Effet sur le conteneur) |
|---|---|
1. securityContext.capabilities.drop: ["ALL"] |
A. Supprime toutes les capacités Linux superflues du noyau pour restreindre les droits du conteneur. |
2. securityContext.privileged: true |
B. Donne un accès total aux périphériques de l'hôte et désactive l'isolation des conteneurs (à proscrire). |
3. securityContext.capabilities.add: ["NET_ADMIN"] |
C. Ajoute sélectivement une capacité spécifique requise (ex. administration réseau locale) sans être root. |
Correction
1-A, 2-B, 3-C