Aller au contenu

Bank 2 – Vrai / Faux (Partie 2 : Configuration / Sécurité)

Instructions

Pour chaque affirmation, choisissez Vrai ou Faux.
Une justification est fournie après validation.

Total : 20 affirmations (5 faciles · 10 moyennes · 5 difficiles)


Niveau Facile

#

Question 1

Un ConfigMap permet de stocker des fichiers de configuration ou des variables sous forme de clé-valeur en texte clair.

#

Question 2

Les valeurs stockées dans un objet Secret Kubernetes standard sont chiffrées par un algorithme AES-256 fort par défaut.

#

Question 3

Dans le modèle RBAC de Kubernetes, un Role s'applique obligatoirement à un Namespace particulier.

#

Question 4

Par défaut, un cluster Kubernetes bloque toutes les communications réseau entre les pods situés dans des namespaces différents.

#

Question 5

Un ServiceAccount fournit une identité gérée aux pods pour s'authentifier auprès de l'API Server de Kubernetes.


Niveau Moyen

#

Question 6

Lorsqu'un ConfigMap est monté sous forme de volume dans un conteneur, la mise à jour des valeurs du ConfigMap est répercutée dans le système de fichiers du conteneur sans avoir à redémarrer le pod.

#

Question 7

Si une variable d'environnement est injectée dans un conteneur depuis un ConfigMap via envFrom, la modification ultérieure du ConfigMap met à jour instantanément la variable dans le processus en cours.

#

Question 8

Un ClusterRoleBinding peut lier un ClusterRole à un utilisateur, lui accordant des privilèges sur l'ensemble du cluster.

#

Question 9

Un RoleBinding ne peut lier qu'un Role de son propre namespace et ne peut en aucun cas faire référence à un ClusterRole.

#

Question 10

Par défaut, lorsqu'un Secret est monté sous forme de volume dans un Pod, Kubernetes utilise un système de fichiers en mémoire (tmpfs) sur le nœud.

#

Question 11

Pour appliquer des règles de sécurité NetworkPolicy dans un cluster, il est suffisant de créer les objets YAML correspondants, quel que soit le plugin CNI utilisé.

#

Question 12

Le champ securityContext.runAsNonRoot: true empêche un conteneur de démarrer si son image tente d'exécuter l'application en tant que root (UID 0).

#

Question 13

La section egress d'une NetworkPolicy définit les règles de filtrage pour le trafic réseau sortant du pod.

#

Question 14

Un utilisateur possédant les droits get, list et watch sur la ressource secrets via RBAC ne peut pas lire le contenu des secrets du namespace.

#

Question 15

La commande kubectl create configmap mon-config --from-file=app.conf crée une entrée dans la ConfigMap où la clé est le nom du fichier (app.conf) et la valeur est son contenu.


Niveau Difficile

#

Question 16

Si une NetworkPolicy contient une liste podSelector ciblant des pods mais ne spécifie aucune règle ingress, tout le trafic entrant vers ces pods est autorisé.

#

Question 17

Dans un fichier de définition de NetworkPolicy, il est possible d'associer un podSelector et un namespaceSelector dans un même élément de règle pour filtrer à la fois selon le namespace et les labels des pods.

#

Question 18

Le paramètre readOnlyRootFilesystem: true dans le securityContext empêche tout processus du conteneur d'écrire sur son système de fichiers racine, renforçant l'immuabilité du conteneur.

#

Question 19

L'automatisation du renouvellement des certificats TLS via Traefik dans k3s repose généralement sur le protocole ACME (utilisé par Let's Encrypt).

#

Question 20

L'activation du chiffrement des secrets au repos (EncryptionConfiguration) dans le cluster re-chiffre automatiquement et instantanément tous les secrets déjà existants dans la base de données.