Kubernetes (8/12) — Secrets & imagePullSecret (Harbor)

L’idée reçue

« Kubernetes peut tirer n’importe quelle image, il suffit de donner son nom. »

Vrai pour les images publiques. Mais ton image SORIA Web est dans Harbor, privé : le cluster reçoit un 401 Unauthorized. Il faut lui donner des identifiants — via un Secret d’un type particulier, l’imagePullSecret. C’est le module qui connecte enfin ton cluster à ton registre.

À la fin de ce module, tu sauras…

Expliquer ce qu’est un Secret Kubernetes et ses principaux types
Créer un imagePullSecret pour Harbor (compte robot)
L’attacher au ServiceAccount pour tout le namespace
Déployer ta propre image privée depuis Harbor

01Un Secret, et ses types

Un Secret stocke des données sensibles (mots de passe, tokens, clés). Il en existe plusieurs types, chacun pour un usage précis :

Type	Utilisé par	Quand
`Opaque`	le conteneur	à l’exécution (env ou fichier)
`dockerconfigjson`	le node (kubelet)	avant le démarrage du conteneur
`TLS`	Ingress / Pod	pour le HTTPS

Comprends celui qui nous intéresse ici

Pour tirer une image privée, c’est le type dockerconfigjson qu’il nous faut : l’imagePullSecret. Point crucial : il est utilisé par le node (kubelet) pendant la phase de téléchargement de l’image — avant que le conteneur ne démarre. Il n’est jamais « dans » le conteneur.

02Le problème, prouvé

Expérience 1

Tirer une image Harbor sans identifiants → échec

Manipule

kubectl run harbor-test \
--image=harbor.mondomaine.fr/soria/soria-web:2.0 \
--restart=Never
kubectl describe pod harbor-test | grep -iE "pull|unauthorized|failed"

Observe

Failed to pull image "...": ... 401 Unauthorized
Error: ErrImagePull  /  ImagePullBackOff

Le node a demandé l’image à Harbor, qui a répondu 401 Unauthorized : le registre est privé. Sans identifiants, pas de pull.

Comprends le flux exact du pull

Pod créé → le kubelet voit l’image harbor… → il vérifie : « le ServiceAccount a-t-il un imagePullSecret ? » → si oui, il s’authentifie auprès de Harbor → le pull réussit → le conteneur démarre. Ici l’étape d’authentification manque. Nettoie : kubectl delete pod harbor-test.

03Créer l’imagePullSecret (compte robot Harbor)

Expérience 2

Donner les identifiants du registre au cluster

On réutilise le compte robot créé en Phase 4 (jamais le compte admin). Ne colle jamais le token dans un fichier versionné — seulement dans le terminal :

Manipule

kubectl -n lab-soria create secret docker-registry harbor-pull \
--docker-server=harbor.mondomaine.fr \
--docker-username='robot$soria+ci' \
--docker-password='&lt;TOKEN&gt;'

Manipule

kubectl -n lab-soria get secret harbor-pull

Observe

NAME          TYPE                             DATA   AGE
harbor-pull   kubernetes.io/dockerconfigjson   1      5s

Le Secret existe, de type dockerconfigjson : il contient les identifiants Harbor, prêts pour le node.

Comprends docker-registry, un raccourci

create secret docker-registry fabrique directement un Secret au format que le kubelet attend (le même ~/.docker/config.json que docker login produit). Serveur + utilisateur robot + token : tout ce qu’il faut pour s’authentifier au pull.

04L’attacher au ServiceAccount

Expérience 3

Le rendre automatique pour tout le namespace

Manipule

kubectl -n lab-soria patch serviceaccount default \
-p '{"imagePullSecrets":[{"name":"harbor-pull"}]}'
kubectl -n lab-soria get serviceaccount default -o yaml | grep -A2 imagePullSecrets

Observe

imagePullSecrets:
- name: harbor-pull

Désormais, tout Pod du namespace utilisant le ServiceAccount default pourra tirer des images Harbor, sans répéter la configuration. C’est ici que le cluster est connecté à Harbor.

Comprends pourquoi via le ServiceAccount

La chaîne : namespace lab-soria → ServiceAccount default → imagePullSecrets: harbor-pull → tous les Pods peuvent tirer d’Harbor. On aurait pu ajouter imagePullSecrets dans chaque Pod, mais l’attacher au ServiceAccount le rend automatique et propre — pratique DevOps standard. Le ServiceAccount est l’identité que prennent les Pods dans le cluster.

05Déployer ta propre image, enfin

Expérience 4

Aligner le Deployment sur l’image Harbor

Manipule

kubectl set image deployment/demo-deploy nginx=harbor.mondomaine.fr/soria/soria-web:2.0
kubectl rollout status deployment/demo-deploy
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.spec.containers[*].image}{"\n"}{end}'

Observe

demo-deploy-xxxxx  harbor.mondomaine.fr/soria/soria-web:2.0
demo-deploy-yyyyy  harbor.mondomaine.fr/soria/soria-web:2.0

Le rollout réussit, et les Pods tournent maintenant sur ton image, tirée du registre privé. La boucle est bouclée : code → image → Harbor → cluster.

Comprends ce que ça signifie pour le projet

Ton image, construite en Phase 3, poussée dans Harbor en Phase 4, tourne désormais dans Kubernetes derrière un Service et un Ingress HTTPS. C’est exactement le circuit d’une application réelle en production. Il ne manque que l’automatisation (Phase 6) pour que tout ça se déclenche sur un simple git push.

✓Ce que tu retiens

Un Secret stocke des données sensibles ; l’imagePullSecret (type dockerconfigjson) donne au node les identifiants pour tirer une image privée, avant le démarrage du conteneur. Attaché au ServiceAccount du namespace, il connecte tout le cluster à Harbor. Ta propre image tourne enfin dans Kubernetes.

Mini-projet

Connecte ton cluster à Harbor

À faire

Prouve l’échec : tente de tirer ton image Harbor sans identifiants (401).
Crée l’imagePullSecret harbor-pull avec le compte robot.
Attache-le au ServiceAccount default du namespace.
Bascule demo-deploy sur ton image Harbor et prouve la version qui tourne.
Documente dans BookStack le flux du pull et le rôle du ServiceAccount.

Fil rouge — Tes Pods tirent la bonne image et détiennent des secrets. Mais comment gérer la configuration (non secrète) de l’appli — URL, couleurs, options — proprement ? Au module suivant : ConfigMap vs Secret.

?Auto-évaluation

1. Qui utilise l’imagePullSecret, et à quel moment ?

Le node (kubelet), pendant la phase de téléchargement de l’image, avant le démarrage du conteneur. Il n’est pas utilisé dans le conteneur.

2. Pourquoi attacher le Secret au ServiceAccount plutôt qu’à chaque Pod ?

Pour que tous les Pods du namespace puissent tirer d’Harbor automatiquement, sans répéter la configuration.

3. Quel type de Secret est un imagePullSecret ?

kubernetes.io/dockerconfigjson — le même format d’identifiants que celui produit par docker login.