Aller au contenu

Kubernetes Mis à jour le 2026-05-27

Contrôle d'accès Kubernetes

Fonctionnement de RBAC sur un cluster Kubernetes Stack Harbor PaaS, le jeton cluster-admin par défaut, et la bonne façon de partager l'accès au cluster avec d'autres utilisateurs.

Un cluster Kubernetes Stack Harbor PaaS gère l’autorisation via le RBAC natif de Kubernetes — ressources Role, ClusterRole, RoleBinding et ClusterRoleBinding liées à des sujets ServiceAccount. Le cluster livre un jeton d’amorçage dont le ServiceAccount porte le rôle cluster-admin ; le reste est à vous de définir.

Cette page est la version courte de ce qu’il faut faire avec ce jeton admin initial et comment accorder un accès limité aux coéquipiers sans distribuer le cluster-admin.

Le jeton par défaut

Après l’installation du cluster, le tableau de bord expose un jeton d’accès. Ce jeton est lié à un ServiceAccount avec le ClusterRoleBinding cluster-admin — il peut tout faire sur le cluster. Traitez-le comme un identifiant root :

  • Hors gestion de version.
  • À utiliser pour l’amorçage et l’outillage admin, pas pour des charges applicatives.
  • Tournez-le si vous suspectez une fuite (supprimez le Secret, le contrôleur le régénère).

Pour le quotidien, surtout en équipe, le jeton cluster-admin est le mauvais outil. Émettez plutôt des ServiceAccount à portée limitée.

Partager l’accès — la bonne forme

Le motif qui tient à l’usage :

  1. Créer un ServiceAccount dédié par humain ou par automatisme qui a besoin d’accès. Un compte par usage rend les pistes d’audit lisibles.
  2. Définir un Role ou ClusterRole qui liste exactement les verbes et ressources nécessaires. Commencez serré (get, list, watch sur pods) et élargissez à la découverte des besoins réels.
  3. Les lier par RoleBinding (portée namespace) ou ClusterRoleBinding (portée cluster).
  4. Distribuer le jeton du ServiceAccount à l’utilisateur ou le coller dans son pipeline CI.

Un premier découpage :

  • Observabilité lecture seule — get, list, watch sur pods, services, deployments, ingresses, events. Utile aux développeurs qui doivent déboguer leur service sans pouvoir modifier l’état du cluster.
  • Propriétaire de namespace — verbes complets limités à un namespace. Permet à une équipe de gérer son application sans voir le reste du cluster.
  • Opérateur de cluster — verbes cluster complets sauf la gestion du RBAC lui-même, réservée à ceux qui exploitent le cluster.
  • Cluster admin — le jeton d’amorçage. En pratique, à n’utiliser pour personne sauf les opérations ponctuelles qui ne se font pas autrement.

Deux mises en garde propres à Stack Harbor

  • Le RBAC Kubernetes n’est pas la même surface que les comptes plateforme. Partager un environnement Kubernetes via la fonction de partage standard de la plateforme expose un accès SSH au nœud maître — et le nœud maître a un kubectl pré-configuré avec le rôle cluster-admin. De fait, toute personne avec qui vous partagez l’environnement par la plateforme peut agir en cluster-admin indépendamment de ce que dit le RBAC. Partagez en conséquence, et tournez la configuration kubectl du nœud maître si vous devez révoquer un accès.
  • Le pare-feu de la plateforme ne contraint pas Kubernetes. Les règles réseau dans le cluster sont gérées dynamiquement par Kubernetes (via le plugin CNI, NetworkPolicy et le contrôleur d’ingress). Les paramètres pare-feu du tableau de bord ne s’appliquent pas au trafic intra-cluster. Pour une politique réseau, définissez des ressources NetworkPolicy.

Voir aussi