Erreur Kubernetes “short name mode is enforcing” : voici pourquoi vos Pods ne démarrent plus

“short name mode is enforcing” : depuis Kubernetes 1.34, ce message d’erreur s’invite dans vos logs et vos Pods se figent en ErrImagePull ou ImageInspectError.

Ce n’est pas un bug : Kubernetes signe officiellement la fin des shortnames, ces images appelées sans registre explicite. Pour vous, c’est un déploiement qui casse. pour Kubernetes et CRI-O 1.34, c’est une façon d’assainir la supply chain des conteneurs et de clarifier la provenance des images.

Dans cet article, on explique ce que signifie vraiment l’erreur “short name mode is enforcing”, pourquoi vos manifests historiques ne passent plus, et ce que K8s attend désormais quand il s’agit de nommer vos images. Place à la magie.

Découvrir nos services DevOps

Rappel : qu’est-ce qu’un shortname sur Kubernetes ?

Dans l’écosystème container, un shortname est un nom d’image incomplet, c’est-à-dire, un nom qui ne précise pas dans quel registre aller chercher l’image.

Par exemple :

nginx:latest ❌
myapp/backend: 1.2 ❌

Dans les deux cas, impossible de savoir si l’image doit être tirée depuis Docker Hub, un registre privé ou autre chose.

À l’inverse, voici des exemples de noms pleinement qualifiés :

docker.io/library/nginx:latest ✅
registry.example.com/myapp/backend:1.2 ✅

Ici, le registre est clairement défini. Aucun doute possible.

Pourquoi utiliser des shortnames ?

Parce que c’était pratique.
Et parce que ça a marché pendant presque dix ans.

Jamais personne ne s’est dit qu’écrire docker.io/library/nginx:1.18 éviterait un incident.

Et pourtant, c’est le cas aujourd’hui.

Comment ça marchait avant ?

Pendant des années, les runtimes comme Docker, Podman ou CRI-O se reposaient sur un mécanisme appelé unqualified-search-registries.

Leur logique était simple : “Tu ne me dis pas où aller ? Très bien, je vais fouiller tous les registres qu’on m’a indiqués. Peut-être que je trouverai ce nginx:latest quelque part.”

Pratique, oui.
Mais aussi trop permissif : plusieurs registres pouvaient contenir le même nom, et le runtime n’avait aucun moyen de savoir lequel utiliser.

Ce qui ne fonctionne plus depuis Kubernetes 1.34

Courant 2025, la release Kubernetes 1.34 marque un tournant. Non pas dans Kubernetes lui-même, mais dans CRI-O 1.34, le runtime utilisé par certaines distributions (OpenShift, OKD 4.15+, Oracle OKE…).

À partir de la version 1.34, toutes les distributions basées sur CRI-O 1.34 appliquent par défaut un mode enforcing pour la résolution des noms d’images.

En d’autres mots :

• Le runtime n’a plus le droit de deviner le registre où se trouve l’image.
• Si vous déployez une image non qualifiée : il la considère ambiguë et retourne une erreur comme : « short name mode is enforcing, but image name nginx:latest returns ambiguous list » .
• Et en cas d’ambiguïté, CRI-O renvoie une erreur immédiate.
• Vos pods se bloquent en ImageInspectError ou ErrImagePull.
  

Aujourd’hui, seuls les noms complets sont acceptés.

Failed to pull image "nginx:1.14.2" :
short name is enforcing,
but image name nginx:1.14.2 returns ambiguous list

En résumé : pourquoi voyez-vous cette erreur ?

Si “short name mode is enforcing” apparaît, c’est simplement que vous utilisez encore des shortnames.
Ils peuvent se cacher dans :

• vos manifests Kubernetes,
• vos Helm charts,
• vos templates Kustomize,
• vos pipelines CI/CD,
• vos initContainers,
• ou des bouts de YAML qui datent d’une autre époque.

Rien de dramatique : il faut juste faire un peu de ménage, qualifier les noms d’image, et surtout, s’accorder sur une politique de nommage standard pour éviter que cela ne se reproduise.

Une règle simple, et une bonne habitude pour la suite.

Si Kubernetes se met soudain à refuser vos images, ce n’est pas un caprice technique. C’est une décision mûrie, presque politique, qui touche à un sujet devenu central : la sécurité de la supply chain. Aujourd’hui, une simple image contrefaite peut compromettre tout un cluster.

Voici les principales raisons derrière ce changement :

Pour mettre fin à l’ambiguïté : un même nom, plusieurs registres

Tapez “nginx” dans n’importe quel registre : vous trouverez une multitude d’images portant ce nom.
Certaines officielles, d’autres modifiées, et d’autres franchement douteuses.
Pendant des années, le runtime devait deviner laquelle vous vouliez.

Avec le mode enforcing, Kubernetes rappelle une règle simple : c’est à vous de préciser la source, pas au runtime de l’inventer.

Pour réduire le risque d’usurpation d’image

Restons sur l’exemple nginx. Publier une image “nginx” piégée sur un registre public, c’est possible en 30 secondes. Si le runtime n’a pas de précisions sur quelle image choisir, il y a de fortes chances qu’il tombe sur une des ces images malveillantes. C’est un scénario d’attaque très courant.

Pour éviter les fuites de credentials

Chaque requête envoyée à un registre non prévu peut embarquer vos identifiants.
C’est le risque d’exposer des secrets sans le vouloir.

Pour s’aligner sur l’écosystème : Podman, Buildah, Red Hat, OKE…

Les environnements orientés sécurité ont déjà tourné la page des shortnames depuis longtemps : Podman, Buildah, OKE, OpenShift… Kubernetes ne fait que rejoindre un mouvement déjà largement amorcé dans l’industrie.

Pour se conformer aux standards du marché

Les standards actuels, provenance, traçabilité, signatures OCI, attestations, exigent une chaîne claire et vérifiable. On ne peut pas sécuriser ce qu’on ne peut pas identifier.
Un nom complet, c’est la base de cette traçabilité.

L’erreur “short name mode is enforcing” n’est que la partie visible du changement.

Derrière, Kubernetes 1.34 et CRI-O 1.34 réorganisent le comportement du cluster : la manière dont les images sont référencées, vérifiées, tirées et résolues.

Et ce changement va au-delà de la simple question : “pourquoi mon Pod ne démarre plus ?”

Il touche à tout : de la manière de versionner vos images jusqu’à la structure de vos Helm charts, vos pipelines CI/CD ou vos environnements de test.

L’architecture d’image devient un sujet d’équipe

Avant Kubernetes 1.34, écrire nginx:latest ou alpine:3 passait pour un détail. Avec CRI-O 1.34, ce détail devient une question d’architecture :

• comment nomme-t-on nos images ?
• quel registre fait autorité ?
• comment garder une cohérence entre dev, staging et prod ?
• quels shortnames dorment encore dans les charts ou les pipelines ?

En forçant les images pleinement qualifiées, Kubernetes impose maintenant une discipline de nommage que beaucoup d’équipes n’avaient jamais vraiment formalisée. Ce changement oblige les équipes à revoir leurs habitudes, mais surtout à collaborer davantage : Dev, Ops, SRE et SecOps… Tout le monde doit désormais parler le même langage d’image.

Les pipelines CI/CD révèlent leurs angles morts

Beaucoup de pipelines reposent encore sur :

• des scripts shell anciens,
• des fragments YAML copiés depuis des charts extérieurs,
• des outils internes qui insèrent des images sans registre,
• des repositories mal ou peu documentés.

Avec Kubernetes 1.34, un simple shortname oublié suffit à :

• interrompre un déploiement,
• casser un rollout,
• bloquer un initContainer,
• ou rendre une étape de test inexécutable.
  
  

Les Helm charts en première ligne

Les Helm charts (en particulier les vieux charts) concentrent une grande partie des shortnames historiques.

Avec Kubernetes 1.34 :

• les valeurs par défaut autrefois anodines deviennent bloquantes,
• des upgrades échouent sans explication apparente,
• des charts tiers doivent être patchés ou forkés,
• des projets dormants sont audités.
  
  

Avec Kubernetes 1.34 et CRI-O 1.34, le cadre devient plus strict : les images doivent être explicites, qualifiées, et traçables. Rien de compliqué, mais un peu de méthode.

Voici les bonnes pratiques à mettre en place pour éviter l’erreur “short name mode is enforcing” et, plus largement, renforcer votre chaîne d’approvisionnement container.

Utiliser systématiquement des images pleinement qualifiées

C’est la règle numéro un, celle qui résout 100 % des erreurs liées au mode enforcing.

Voici quelques exemples de noms pleinement qualifiés :
✔️ docker.io/library/nginx:1.18
✔️ registry.example.com/app/backend:2.5.1
✔️ quay.io/organisation/service:1.0.7

Pour rappel, un nom d’image complet est un nom qui :

• supprime toute ambiguïté
• clarifie la provenance
• renforce la sécurité
• évite les ErrImagePull
• améliore la reproductibilité des environnements
  
  

Nettoyer les charts, les manifests, les pipelines

Les shortnames se cachent partout : dans un values.yaml, un vieux deployment.yaml, un job CI oublié, une image d’initContainer copiée il y a cinq ans.

Attention surtout aux Helm charts de la communauté : beaucoup de charts publics, très populaires, continuent d’utiliser des shortnames. Avec Kubernetes 1.34, cela ne passe plus du tout.

Pour éviter les surprises, nous vous conseillons de faire un audit complet de :

• vos Helm charts (internes et externes)
• vos manifests Kubernetes
• vos kustomizations
• vos scripts CI/CD
• vos CRONJobs
• vos jobs d’intégration
• vos images par défaut dans les dépendances
  

Ce n’est pas forcément long, mais c’est essentiel. Beaucoup d’équipes découvrent à cette occasion des comportements qu’elles n’avaient jamais identifiés.

Organiser clairement son registry interne

L’erreur “short name mode is enforcing” est souvent le symptôme d’une configuration floue côté registry. Pour éviter les ambiguïté :

• évitez d’avoir plusieurs registres dans unqualified-search-registries
• harmonisez vos conventions (namespace, arborescence, versionnement, rétention)
• documentez ce qui fait autorité.
  

Un registry bien structuré réduit mécaniquement les sources d’erreur, et clarifie les responsabilités entre équipes.

Éviter les registres publics dans unqualified-search-registries

unqualified-search-registries, c’est la liste des registres que CRI-O va consulter lorsqu’une image n’est pas pleinement qualifiée. Autrement dit : si votre manifeste contient nginx:latest au lieu d’un nom complet, CRI-O regarde dans cette liste pour décider où aller chercher l’image.

L’un des pièges les plus fréquents est d’avoir plusieurs registres publics dans cette liste, par exemple :

unqualified-search-registries = ["docker.io", "quay.io"]

Dans ce cas, CRI-O voit plusieurs sources possibles pour une même image (nginx, redis, alpine…), ce qui crée immédiatement une ambiguïté. En mode enforcing, cette ambigüité suffit pour qu’il renvoie l’erreur « short name mode is enforcing ».

C’est pourquoi la configuration la plus sûre, aujourd’hui, est la plus minimaliste :

unqualified-search-registries = []

Ou, si un registre interne doit être utilisé comme référence :

unqualified-search-registries = ["<registry-interne>"]

Plus cette liste est courte, plus le comportement de CRI-O est prévisible, et moins vous risquez de vous heurter à l’erreur.

Ne pas désactiver le mode enforcing

Oui, il est possible de désactiver cette protection : short_name_mode = « disabled »

Mais ce n’est pas recommandé. Cela revient à rétablir les comportements d’avant… et les mêmes risques. Ce contournement ne doit servir qu’en transition, le temps de qualifier proprement vos images. Il ne constitue pas une stratégie durable.

Voilà : vous savez maintenant pourquoi le message “short name mode is enforcing” apparaît, et ce qui se cache derrière ces Kubernetes 1.34 breaking changes.

C’est une évolution logique : CRI-O 1.34 ne veut plus deviner, et Kubernetes met fin à une pratique, disons-le, risquée. Kubernetes est devenu un standard, et comme tout standard, il impose peu à peu des pratiques plus sûres et plus explicites.

La solution est simple : utiliser des images pleinement qualifiées, clarifier votre registry, et mettre à jour charts et pipelines. Une fois ces points traités, l’erreur disparaît, et votre cluster retrouve un comportement prévisible.

Et si vous avez besoin d’un coup de main pour remettre de l’ordre dans vos images, vos charts ou vos pipelines, on a toujours un magicien DevOps prêt à intervenir pour vous aider.

Méfait accompli.