Gérer vos clusters Kubernetes avec Rancher de SUSE

Rancher est une interface unique pour créer, importer et exploiter plusieurs clusters Kubernetes à la fois. Ce guide installe Rancher 2.15.1 sur un k3s mono-nœud par Helm, et publie les sorties réelles d'une machine montée le 20 septembre 2026. Il s'adresse à qui connaît déjà kubectl et veut un point d'entrée unique sur plusieurs clusters, en homelab ou avant une mise en production.

Trois choses vous éviteront de perdre une soirée : le chart refuse Kubernetes 1.37, la voie Docker que l'on trouve partout est un banc d'essai sans reprise possible, et les guides d'avant 2025 proposent encore de créer des clusters RKE1, qui n'existe plus.

Ce que vous allez apprendre

• Choisir entre conteneur unique, k3s mono-nœud et cluster dédié, selon ce que vous comptez en faire
• Vérifier la matrice de support avant de provisionner, avec helm show chart
• Installer Rancher par Helm sur k3s, cert-manager compris, sans mode privilégié
• Atteindre l'interface et diagnostiquer un Ingress qui ne répond pas
• Créer ou importer un cluster, et savoir ce que Rancher pilote dans chaque cas
• Restreindre les Pods avec Pod Security Admission, qui remplace les PodSecurityPolicy disparues

Historique de Rancher

L'histoire de Rancher commence bien avant son acquisition par SUSE, marquant une évolution significative dans le monde de la gestion de conteneurs. Rancher Labs a été fondé en 2014, avec la vision de simplifier la gestion des conteneurs pour les entreprises. Le produit phare, Rancher, est rapidement devenu populaire en raison de sa facilité d'utilisation et de sa polyvalence, offrant une plateforme complète pour la gestion des clusters Kubernetes.

La force de Rancher réside dans sa capacité à rendre Kubernetes accessible, même pour les équipes sans expérience préalable en matière de conteneurs. Cette accessibilité a été un facteur clé de son adoption rapide par une vaste communauté d'utilisateurs. Rancher a évolué pour prendre en charge une variété de distributions Kubernetes, rendant la plateforme attrayante pour une large gamme d'environnements informatiques, des PME aux grandes entreprises.

En 2020, SUSE, une entreprise leader dans le domaine des logiciels open source, a acquis Rancher Labs. Cette acquisition a marqué un tournant stratégique pour SUSE, lui permettant de renforcer son portefeuille de solutions de gestion de cloud et de conteneurs. L'intégration de Rancher dans l'écosystème SUSE a non seulement élargi les capacités de la plateforme mais a également bénéficié à la communauté d'utilisateurs de SUSE en leur offrant une solution de gestion de conteneurs de classe entreprise.

Sous l'égide de SUSE, Rancher continue d'évoluer, en se concentrant sur l'innovation et l'amélioration continue. L'accent est mis sur la simplification de la gestion des opérations Kubernetes, la sécurité renforcée et la prise en charge étendue des environnements cloud hybrides et multicloud. Cette approche holistique de la gestion des conteneurs permet aux entreprises de toutes tailles de tirer pleinement parti de la puissance et de la flexibilité de Kubernetes, tout en minimisant la complexité et les coûts associés.

Ce que Rancher apporte concrètement

Rancher se distingue par un ensemble de fonctionnalités robustes et intégrées, conçues pour répondre aux besoins des entreprises dans la gestion de leurs environnements Kubernetes. Voici les plus importantes :

• Gestion Multi-Clusters : Une des grandes forces de Rancher est sa capacité à gérer plusieurs clusters Kubernetes, qu'ils soient hébergés sur site, dans le cloud ou dans des environnements hybrides. Cette fonctionnalité permet aux administrateurs de centraliser la gestion de leurs clusters, de simplifier les déploiements et d'uniformiser les opérations, tout en conservant une visibilité complète sur l'ensemble de leur infrastructure.

• Sécurité et Conformité : Rancher intègre des fonctionnalités de sécurité avancées pour assurer la protection des clusters Kubernetes. Il propose des contrôles d'accès basés sur les rôles (RBAC), la gestion des politiques de sécurité et la conformité aux normes de sécurité. Ces fonctionnalités aident les organisations à maintenir des environnements Kubernetes sécurisés et conformes aux réglementations en vigueur.

• Catalogue d'Applications : Rancher inclut un catalogue d'applications qui facilite le déploiement de services et d'applications dans les clusters Kubernetes. Ce catalogue est une ressource précieuse pour les équipes de développement, leur permettant de déployer rapidement des applications pré-configurées, réduisant ainsi le temps de mise sur le marché.

• Support des Environnements Cloud Hybrides et Multicloud : Rancher prend en charge une large gamme d'environnements cloud, permettant aux entreprises d'exécuter leurs applications où elles le souhaitent. Cette flexibilité est essentielle dans un monde où les architectures cloud hybrides et multicloud deviennent la norme.

• Observabilité et Monitoring : La plateforme fournit des outils complets pour le monitoring et l'observabilité des clusters Kubernetes. Ces outils aident les équipes à surveiller la performance, à détecter et à résoudre rapidement les problèmes, garantissant ainsi une haute disponibilité et performance des applications.

• Intégration avec des Outils Externes : Rancher s'intègre facilement avec une variété d'outils DevOps et de sécurité, permettant aux équipes de continuer à utiliser leurs outils préférés tout en bénéficiant des avantages de Rancher.

Installation de Rancher

Deux chemins mènent à un Rancher qui démarre, et ils n'ont pas les mêmes conséquences six mois plus tard. Le premier se lance en une commande et ne se sauvegarde pas ; le second demande un cluster Kubernetes et se maintient. Cette section pose d'abord le choix, puis déroule les deux.

Quelle architecture selon l'usage

Rancher s'installe de deux façons, et elles ne servent pas le même usage. Choisissez d'abord, installez ensuite : la voie Docker mène à une impasse dès qu'on veut une sauvegarde ou une montée de version.

Usage	Architecture	Pourquoi
Découverte, une heure pour voir l'interface	conteneur unique	rapide, jetable, aucune reprise possible
Homelab, on veut garder ses clusters	k3s mono-nœud, Rancher par Helm	sauvegarde et montée de version réelles
Production	Kubernetes dédié, Rancher par Helm, plusieurs répliques	Rancher ne partage pas le cluster qu'il gère

Glissez pour voir

La troisième ligne mérite d'être dite clairement : Rancher s'installe sur un cluster qui lui est réservé, distinct de ceux qu'il pilote. Installer le gestionnaire sur un cluster de production revient à perdre l'outil de reprise en même temps que ce qu'il devait aider à reprendre.

La version de Kubernetes que Rancher accepte n'est pas la dernière

Le chart Rancher refuse d'installer sur un Kubernetes trop récent, et il le dit clairement. Mesuré le 20 septembre 2026, chart Rancher 2.15.1 sur un k3s 1.37.0 fraîchement monté :

Error: chart requires kubeVersion: < 1.37.0-0
       which is incompatible with Kubernetes v1.37.0+k3s1

C'est un refus propre, pas une panne : rien n'est installé, le message nomme la contrainte. Mais il surprend, parce qu'on monte spontanément le Kubernetes le plus récent. Vérifiez la contrainte avant de provisionner le cluster :

helm show chart rancher-stable/rancher --version 2.15.1 | grep -i kubeversion

Versions retenues pour ce guide, toutes relevées le 20 septembre 2026 :

Composant	Version	Remarque
Rancher	2.15.1	chart Helm et application
Kubernetes	k3s 1.36.4	1.37 refusée par le chart
cert-manager	1.21.2	prérequis du chart
Helm	4.3.0

Glissez pour voir

Découvrir avec un conteneur unique

Cette voie est un banc d'essai, pas une installation

La commande ci-dessous démarre Rancher en mode privilégié, ce qui donne au conteneur un accès équivalent à root sur l'hôte. C'est acceptable sur une machine jetable, et seulement là : ni sur un poste de travail, ni sur un serveur partagé, ni sur quoi que ce soit qui porte autre chose.

Elle ne permet par ailleurs ni sauvegarde, ni montée de version, ni haute disponibilité. Ce que vous y créerez sera perdu.

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 --name rancher --privileged \
  rancher/rancher:v2.15.1@sha256:5f6c4dc52a05e0c400b53c08bf778ca55790f277e443b5881269158499b7ebe5

L'image est épinglée par version et par empreinte, et pas laissée sur un tag mouvant : sans cela, le banc d'essai que vous montez aujourd'hui et celui que vous remonterez dans six mois ne sont pas le même logiciel, et la comparaison ne veut plus rien dire.

Ce qu'il faut pour le banc d'essai

• Un serveur Linux jetable avec accès root et suffisamment d'espace disque.
• Docker installé sur ce serveur.

Ouvrir l'interface du banc d'essai

Une fois Rancher lancé, accédez à l'interface web de Rancher en ouvrant un navigateur web et en saisissant l'adresse IP de votre serveur http://<IP_SERVEUR>.

• Dans l'interface web de Rancher, suivez les instructions pour configurer un mot de passe administrateur et l'URL du serveur Rancher.

Le mot de passe créé pendant l'installation peut être récupéré avec la commande suivante :

docker logs rancher |grep 'Bootstrap Password'

Installation sur un cluster K3s

C'est la voie à retenir dès que vous comptez garder ce que vous créez. Elle demande un cluster, cert-manager, et une version de Kubernetes compatible avec le chart, mais elle donne en échange la sauvegarde, la montée de version et la haute disponibilité que la voie Docker ne permet pas.

Ce qu'il faut pour l'installation k3s

Cette voie est celle que je valide et que je rejoue. Les sorties publiées plus bas viennent toutes de la même machine, montée le 20 septembre 2026 :

Élément	Ce que j'ai utilisé	Pourquoi ce choix
Machine	Ubuntu 24.04, 4 vCPU, 8 Go de RAM, 30 Go de disque	Rancher réclame de la mémoire, en dessous de 8 Go le pod redémarre
Kubernetes	k3s v1.36.4+k3s1	la 1.37 est refusée par le chart, voir plus haut
Ingress	Traefik, le défaut de k3s	c'est lui qui donnera son adresse à l'Ingress de Rancher

Glissez pour voir

Un seul nœud suffit pour apprendre. Les commandes ci-dessous supposent un kubectl qui pointe sur ce cluster, ce que k3s fournit dans /etc/rancher/k3s/k3s.yaml.

Ne désactivez pas Traefik sur ce cluster

Si votre k3s tourne avec --disable traefik, l'Ingress créé par le chart Rancher existera sans que rien ne le serve : kubectl get ingress affichera une colonne CLASS à <none> et une colonne ADDRESS vide, indéfiniment. Mesuré sur ce lab, où k3s était justement démarré ainsi. Ce n'est pas une panne de Rancher, c'est un cluster sans contrôleur d'entrée.

Poser le namespace, le certificat et les dépôts

Trois choses précèdent le helm install : un namespace dédié, un certificat pour le nom que servira l'Ingress, et les dépôts Helm de cert-manager et de Rancher. Les faire dans cet ordre évite l'échec le plus courant, un chart qui s'installe avant que ses prérequis existent.

Une fois déployé, créons le namespace :

kubectl create namespace cattle-system
kubectl config set-context --current --namespace=cattle-system

Il faut ensuite créer un certificat avec mkcert :

mkcert -cert-file tls.crt -key-file tls.key rancher.lab.local

Créons le secret :

kubectl create secret tls tls-rancher-ingress --cert=tls.crt --key=tls.key

Il faut ensuite ajouter les dépôts Helm. Deux canaux existent, et le choix n'est pas neutre : stable porte la version recommandée en production, latest porte la dernière publiée, y compris des versions que SUSE ne recommande pas encore.

helm repo add jetstack https://charts.jetstack.io
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm repo update

cert-manager est un prérequis du chart, pas une option : sans lui, l'installation échoue sur des ressources personnalisées manquantes.

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --version v1.21.2 --set crds.enabled=true --wait

Puis Rancher lui-même, avec sa version épinglée :

helm install rancher rancher-stable/rancher \
  --namespace cattle-system --create-namespace \
  --version 2.15.1 \
  --set hostname=rancher.lab.local \
  --set ingress.tls.source=secret \
  --set replicas=1 \
  --wait --timeout 15m

--version n'est pas une précaution de puriste : sans elle, deux installations faites à quinze jours d'écart donnent deux versions différentes, et la seconde peut refuser votre cluster comme on vient de le voir. replicas=1 vaut pour un nœud unique ; en production, on laisse le défaut à trois et on a trois nœuds pour les porter.

Ce que cette voie évite, et ce qu'elle ne fait pas

Le déploiement Helm ne demande aucun privilège, ce qui est l'argument décisif contre la voie Docker. Vérifié sur l'installation ci-dessus :

kubectl -n cattle-system get deploy rancher \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
# rancher/rancher:v2.15.1

kubectl -n cattle-system get deploy rancher \
  -o jsonpath='{.spec.template.spec.containers[0].securityContext}{"\n"}'
# (vide)

La seconde sortie mérite d'être lue pour ce qu'elle est : le conteneur ne demande pas le mode privilégié, et c'est déjà beaucoup par rapport au --privileged de la voie Docker. Mais il ne déclare aucun contexte de sécurité du tout : ni runAsNonRoot, ni readOnlyRootFilesystem, ni suppression de capacités. Le durcissement du pod reste à votre charge, par une politique d'admission au niveau du cluster.

Suivre le déploiement ne demande pas de recopier un nom de pod à la main, qui change à chaque installation :

kubectl -n cattle-system get pods -l app=rancher

NAME                       READY   STATUS    RESTARTS   AGE
rancher-6f9b9d6595-4bm97   1/1     Running   0          109s

Attendez le 1/1, pas le Running. Relevé sur le lab : le pod est ContainerCreating pendant qu'il tire une image de près de deux gigaoctets, passe Running à 72 secondes, puis n'est déclaré prêt qu'à 109 secondes, le temps d'appliquer ses migrations et d'enregistrer ses ressources personnalisées. Pendant ces trente-sept secondes, ses propres journaux signalent un rancher-webhook encore sans endpoint : le service existe, il n'est pas encore opérationnel. Pour suivre sans recopier le nom du pod :

kubectl -n cattle-system logs -f deploy/rancher

Ouvrir l'interface après l'installation Helm

L'Ingress créé par le chart prend l'adresse que lui donne Traefik, et c'est celle-là qu'il faut résoudre. Les deux commandes suivantes disent tout :

kubectl get ingressclass
kubectl -n cattle-system get ingress

NAME                CONTROLLER                      PARAMETERS   AGE
traefik (default)   traefik.io/ingress-controller   <none>       67s

NAME      CLASS     HOSTS               ADDRESS       PORTS     AGE
rancher   traefik   rancher.lab.local   10.10.66.11   80, 443   65s

Le chart inscrit la classe d'entrée au moment de l'installation, à partir de l'IngressClass marquée (default) sur le cluster. C'est un détail qui a des conséquences : si vous installez Rancher sur un cluster sans contrôleur d'entrée, puis que vous en ajoutez un ensuite, le champ reste vide. Mesuré sur ce lab dans les deux ordres :

kubectl -n cattle-system get ingress rancher -o jsonpath='{.spec.ingressClassName}'
# traefik      Traefik présent AVANT l'installation du chart
# (vide)       Traefik installé APRÈS

Un Ingress sans ingressClassName reste servi tant qu'une IngressClass porte la mention (default). Le jour où plusieurs contrôleurs coexistent, ou si le défaut disparaît, il n'est plus servi par personne, et rien dans Rancher ne vous préviendra. Installez le contrôleur d'entrée avant Rancher, c'est l'ordre qui évite d'avoir à corriger le champ après coup.

L'ADDRESS est l'adresse du nœud, que le ServiceLB de k3s publie pour le service Traefik. Ajoutez-la à votre /etc/hosts :

echo "10.10.66.11 rancher.lab.local" | sudo tee -a /etc/hosts

Vérifiez avant d'ouvrir le navigateur, cela évite de confondre un problème de résolution avec un problème de Rancher :

curl -sk -o /dev/null -w '%{http_code}\n' -H 'Host: rancher.lab.local' https://10.10.66.11/
# 200

curl -sk -o /dev/null -w '%{http_code}\n' https://10.10.66.11/
# 404

Le 404 sans en-tête Host est le comportement attendu, pas une panne : Traefik route sur le nom, et une requête qui n'en porte aucun ne correspond à aucune règle. Si les deux commandes rendent 404, c'est l'Ingress qu'il faut regarder ; si la première rend 200, ouvrez https://rancher.lab.local et vous obtenez cet écran :

Le mot de passe de premier accès n'est pas affiché à l'écran : il est déposé dans un Secret du cluster, que vous lisez vous-même.

kubectl -n cattle-system get secret bootstrap-secret \
  -o go-template='{{.data.bootstrapPassword|base64decode}}{{"\n"}}'

La commande rend une chaîne aléatoire de 23 caractères sur Rancher 2.15.1, propre à votre installation. Changez-la à la première connexion : ce Secret reste lisible par quiconque obtient un droit de lecture sur le namespace cattle-system, et il ne tourne pas tout seul.

Ne publiez jamais ce mot de passe, même sur un lab

Le mot de passe de bootstrap ouvre un compte administrateur de tous les clusters gérés. Il n'a rien à faire dans une capture d'écran, un ticket, un message d'équipe ni un guide. Si vous devez montrer la commande, montrez-la sans sa sortie, comme ci-dessus.

Utilisation de Rancher

Rancher installé ne gère encore rien : il attend qu'on lui confie des clusters. Cette section couvre les trois gestes qui suivent la première connexion, dans l'ordre où on les fait : rattacher un cluster, déclarer une cible de virtualisation, puis déployer des applications depuis le catalogue.

Créer un cluster ou en importer un : ce que Rancher pilote

Rancher sait faire deux choses très différentes avec un cluster : en créer un de toutes pièces sur une infrastructure que vous lui confiez, ou importer un cluster qui existe déjà et tourne sans lui. Le choix est structurant, parce qu'il détermine qui reste responsable du cycle de vie du cluster.

Méthode	Ce que Rancher pilote	Quand la choisir
Importer (Import Existing)	Rien du cycle de vie : il observe, applique du RBAC et des politiques	Cluster managé (EKS, AKS, GKE, Kapsule), ou cluster déjà en production
Provisionner RKE2	Tout : nœuds, version, montée de version, etcd	Machines nues ou VM que vous fournissez, besoin de durcissement CIS
Provisionner K3s	Tout, avec une empreinte réduite	Périphérie, IoT, petits clusters, laboratoires
Provisionner chez un cloud	Le cluster managé via l'API du fournisseur	Vous voulez un point d'entrée unique sur plusieurs clouds

Glissez pour voir

RKE1 n'est plus provisionnable, et ce n'est pas réversible

Les guides antérieurs à 2025 proposent de créer un cluster RKE personnalisé. Cette voie n'existe plus. RKE (RKE1) est en fin de vie depuis le 31 juillet 2025, et les notes de version de Rancher sont explicites : « Rancher versions 2.12.0 and later no longer support provisioning or managing downstream RKE1 clusters ». La version documentée ici, 2.15.1, est très au-delà de ce seuil.

SUSE indique par ailleurs qu'un replatforming sur place est impossible : on ne met pas RKE1 à niveau vers RKE2, on déploie un nouveau cluster et on y migre les charges. Si vous exploitez encore du RKE1, c'est une migration à planifier, pas une mise à jour à passer un soir.

Une fois la méthode choisie, Rancher guide la configuration : version de Kubernetes, ressources de calcul, plugin réseau. C'est aussi là que se posent les garde-fous d'accès, avec les rôles RBAC (Role-Based Access Control) que Rancher projette sur le cluster aval, et l'application des Pod Security Standards décrite plus bas.

Piloter des machines virtuelles avec Harvester

Harvester est la solution d'hyperconvergence open source de SUSE : des machines virtuelles gérées par Kubernetes, sur du matériel nu. Déclaré comme cluster dans Rancher, il devient une cible de provisionnement au même titre qu'un fournisseur cloud, et la même interface pilote alors les conteneurs et les machines virtuelles. C'est l'intérêt réel de l'intégration : ne pas tenir deux consoles pour un parc mixte.

Déployer des applications depuis le catalogue

Rancher embarque un catalogue de charts Helm, accessible depuis Apps > Charts sur un cluster donné. Il sert autant à installer les composants de Rancher lui-même, comme le bench CIS, l'opérateur de sauvegarde ou la pile de supervision, qu'à déployer vos propres applications. Chaque entrée reste un chart Helm ordinaire : ce que vous installez ainsi apparaît dans helm list -A et se désinstalle de la même façon. C'est le point important, parce qu'il détermine comment vous reprendrez la main le jour où l'interface ne répond plus.

Sécurité et conformité des clusters gérés

Deux besoins se confondent souvent et se traitent séparément : empêcher un Pod dangereux de démarrer, et prouver à un auditeur que le cluster est conforme. Le premier relève d'un contrôleur d'admission, le second d'un rapport. Rancher répond aux deux, mais pas avec les mêmes outils, et l'un des deux n'est pas installé par défaut.

Comment Rancher restreint les Pods depuis la disparition des PSP

Le mécanisme est Pod Security Admission (PSA), et il ne se configure pas du tout comme l'ancien. Les PodSecurityPolicy ont été dépréciées en Kubernetes 1.21 puis retirées en 1.25 : tout guide qui vous propose encore d'y écrire des politiques décrit une ressource que l'API refuse. Le remplaçant est un contrôleur d'admission intégré, qui ne juge plus les Pods à partir d'objets dédiés mais à partir de labels posés sur le namespace.

PSA combine trois niveaux, définis par les Pod Security Standards (PSS), et trois modes qui décident du sort d'une violation :

Niveau	Ce qu'il autorise
privileged	Tout, y compris les escalades de privilèges connues
baseline	Interdit les escalades les plus courantes, reste compatible avec la majorité des charges
restricted	Applique les bonnes pratiques de durcissement, le plus strict

Glissez pour voir

Mode	Effet d'une violation
enforce	Le Pod est rejeté
audit	Le Pod passe, une annotation est ajoutée au journal d'audit
warn	Le Pod passe, l'utilisateur reçoit un avertissement

Glissez pour voir

Le label se pose au format pod-security.kubernetes.io/<MODE>: <NIVEAU>, et un namespace peut porter les trois modes avec des niveaux différents. C'est ce qui permet de mesurer avant de bloquer, et la différence entre les deux se voit sur la sortie. D'abord le mode qui observe :

kubectl label namespace paiements \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted --overwrite

kubectl apply -n paiements -f pod-non-conforme.yaml

Le Pod est créé, et l'avertissement nomme chaque manquement :

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false
(container "sonde" must set securityContext.allowPrivilegeEscalation=false), unrestricted
capabilities (container "sonde" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "sonde" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "sonde" must set securityContext.seccompProfile.type to
"RuntimeDefault" or "Localhost")
pod/sonde created

Une fois ces quatre points corrigés, on bascule en blocage :

kubectl label namespace paiements \
  pod-security.kubernetes.io/enforce=restricted --overwrite

kubectl apply -n paiements -f pod-non-conforme.yaml

Le même manifeste est cette fois refusé par l'API, avec la même liste :

Error from server (Forbidden): error when creating "pod-non-conforme.yaml": pods "sonde"
is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false
(container "sonde" must set securityContext.allowPrivilegeEscalation=false), unrestricted
capabilities (container "sonde" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "sonde" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "sonde" must set securityContext.seccompProfile.type to
"RuntimeDefault" or "Localhost")

Le mot would de l'avertissement est le seul écart entre les deux messages : c'est votre indicateur que le namespace n'est pas encore en blocage.

L'apport propre à Rancher, depuis la version 2.7.2, ce sont les PSA Configuration Templates : au lieu d'étiqueter les namespaces un par un, vous choisissez un modèle au niveau du cluster, dans un menu déroulant à la création ou à l'édition. Deux modèles sont créés dès l'installation :

kubectl get podsecurityadmissionconfigurationtemplates

NAME                 AGE
rancher-privileged   29s
rancher-restricted   29s

rancher-privileged ne restreint rien. rancher-restricted applique restricted sur les trois modes à la fois, et surtout exempte d'avance les namespaces des composants, sans quoi le cluster ne démarrerait pas lui-même :

kubectl get podsecurityadmissionconfigurationtemplate rancher-restricted \
  -o jsonpath='{.configuration.defaults}'
# {"audit":"restricted","audit-version":"latest","enforce":"restricted",
#  "enforce-version":"latest","warn":"restricted","warn-version":"latest"}

kubectl get podsecurityadmissionconfigurationtemplate rancher-restricted \
  -o jsonpath='{.configuration.exemptions.namespaces[*]}' | tr ' ' '\n' | grep -c .
# 23

Ces 23 namespaces exemptés méritent d'être lus avant de croire le cluster durci : kube-system, cattle-system, cattle-fleet-system, cattle-monitoring-system, longhorn-system, istio-system et tigera-operator en font partie. Le modèle protège vos charges, pas l'infrastructure qui les porte. Relevé sur Rancher 2.15.1, le 20 septembre 2026.

Le niveau restricted casse des charges légitimes

restricted interdit notamment l'exécution en root, les capacités Linux ajoutées et les montages hostPath. Beaucoup d'images publiques, y compris des bases de données courantes, ne démarrent pas sous ce niveau sans adaptation. Commencez toujours par warn et audit, lisez ce qui remonte, corrigez, et ne passez enforce qu'ensuite. Basculer directement un namespace de production en enforce=restricted est le moyen le plus rapide de déclencher un incident.

Rapports de conformité et bench CIS

Produire la preuve attendue par un auditeur est un besoin distinct de celui de bloquer un Pod, et Rancher ne l'embarque pas : c'est un chart à installer depuis Apps > Charts, nommé CIS Benchmark. Sous le capot, il ne réinvente rien non plus, il orchestre kube-bench d'Aqua Security pour jouer les contrôles du CIS Kubernetes Benchmark, et Sonobuoy pour agréger le résultat à l'échelle du cluster.

Une fois installé, une ressource ClusterScan déclenche un scan selon un ClusterScanProfile ; le profil par défaut laisse Rancher choisir celui qui correspond au type de cluster et à sa version de Kubernetes. Le rapport se lit dans l'interface et s'exporte en CSV, ce qui en fait la pièce à joindre à un dossier RGPD, HIPAA ou PCI-DSS.

Un seul scan à la fois par cluster

Créer plusieurs ClusterScan ne les parallélise pas : ils s'exécutent l'un après l'autre et restent en Pending tant que le scan actif n'est pas terminé. Sur un parc, prévoyez la file d'attente plutôt que de déclencher tout en même temps avant une revue.

Sécurité runtime des conteneurs avec NeuVector

NeuVector fournit une solution de sécurité des conteneurs complète qui s'intègre parfaitement avec Rancher. Cette intégration offre une protection en temps réel contre les menaces internes et externes, améliorant la sécurité globale des applications et des données dans les clusters Kubernetes. Avec NeuVector, vous bénéficiez d'une visibilité complète sur le trafic réseau des conteneurs, permettant la détection et la prévention des activités suspectes ou malveillantes.

Superviser les clusters depuis Rancher

La supervision n'est pas installée par défaut : c'est un chart du catalogue, rancher-monitoring, qui déploie une pile Prometheus et Grafana dans le cluster ciblé. Rancher n'invente rien ici, il pose des composants standards et vous en donne l'accès depuis son interface.

Deux conséquences pratiques. La pile consomme les ressources du cluster supervisé, ce qui se sent sur un nœud unique de laboratoire. Et comme elle s'installe par cluster, superviser dix clusters veut dire dix piles, sauf à brancher une collecte centrale. Pour le détail de ces composants, voir Prometheus et Grafana.

À retenir

• Le chart Rancher 2.15.1 refuse Kubernetes 1.37, contrainte kubeVersion: < 1.37.0-0. Vérifiez-la avec helm show chart avant de provisionner le cluster, sinon vous le remontez.
• La voie Docker est un banc d'essai, pas une installation : --privileged, aucune sauvegarde, aucune montée de version. La voie Helm sur k3s n'exige aucun mode privilégié, c'est l'argument décisif.
• Rancher s'installe sur un cluster qui lui est réservé. Le mettre sur le cluster de production revient à perdre l'outil de reprise avec ce qu'il devait aider à reprendre.
• RKE1 est mort : fin de vie le 31 juillet 2025, provisionnement retiré depuis Rancher 2.12.0, et aucune montée de version sur place vers RKE2. C'est une migration, pas une mise à jour.
• PodSecurityPolicy n'existe plus depuis Kubernetes 1.25. Le mécanisme est Pod Security Admission, avec trois niveaux et trois modes. Passez par warn et audit avant enforce.
• Le modèle rancher-restricted durcit vos charges mais exempte 23 namespaces d'infrastructure : ne le confondez pas avec un cluster durci de bout en bout.
• Le conteneur Rancher ne déclare aucun securityContext : ni runAsNonRoot, ni readOnlyRootFilesystem, ni suppression de capacités. Le durcissement du pod reste à votre charge.
• Le mot de passe de bootstrap ouvre un compte administrateur de tous les clusters gérés. Changez-le à la première connexion, ne le publiez jamais.

Prochaines étapes

k3s Le Kubernetes léger sur lequel repose l'installation validée dans ce guide.

RBAC Kubernetes Les rôles et liaisons que Rancher projette sur les clusters qu'il pilote.

NeuVector La sécurité runtime des conteneurs, intégrée à Rancher.

Harvester L'hyperconvergence SUSE, pilotable depuis la même interface.

×

📖 Voir la documentation →