Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Rôles de cluster et de projet

Les rôles de cluster et de projet définissent l’autorisation des utilisateurs à l’intérieur d’un cluster ou d’un projet.

Pour gérer ces rôles,

  1. Cliquez sur ☰ > Utilisateurs et authentification.

  2. Dans la barre de navigation à gauche, cliquez sur Modèles de rôle et allez à l’onglet Cluster ou Projet/Espaces de noms.

Adhésion et attribution de rôle

Les projets et clusters accessibles aux utilisateurs non administrateurs sont déterminés par l’adhésion. L’adhésion est une liste d’utilisateurs ayant accès à un cluster ou un projet spécifique en fonction des rôles qui leur ont été attribués dans ce cluster ou projet. Chaque cluster et projet comprend un onglet qu’un utilisateur ayant les autorisations appropriées peut utiliser pour gérer l’adhésion.

Lorsque vous créez un cluster ou un projet, Rancher vous attribue automatiquement le rôle de Owner pour celui-ci. Les utilisateurs assignés au rôle de Owner peuvent attribuer d’autres rôles aux utilisateurs dans le cluster ou le projet.

Les utilisateurs non administrateurs ne peuvent pas accéder à des projets/clusters existants par défaut. Un utilisateur ayant les autorisations appropriées (généralement le propriétaire) doit explicitement attribuer l’adhésion au projet et au cluster.

Rôles de cluster

Les rôles de cluster sont des rôles que vous pouvez attribuer aux utilisateurs, leur accordant l’accès à un cluster. Il existe deux rôles de cluster principaux : Owner et Member.

  • Propriétaire de cluster :

    Ces utilisateurs ont un contrôle total sur le cluster et toutes les ressources qu’il contient.

  • Membre de cluster :

    Ces utilisateurs peuvent voir la plupart des ressources au niveau du cluster et créer de nouveaux projets.

    Lorsqu’un Membre de cluster crée un projet, l’utilisateur se voit automatiquement attribuer les privilèges de Propriétaire de projet. Cela leur accorde un contrôle complet sur le projet et ses ressources associées, y compris les autorisations pour déployer des charges de travail. Sans Normes de sécurité des pods (PSS) et Admission de sécurité des pods (PSA) appliquées, un Membre de cluster peut exécuter des conteneurs privilégiés dans le cluster.

Rôles de cluster personnalisés

Rancher vous permet d’attribuer des rôles de cluster personnalisés à un utilisateur standard au lieu des rôles typiques Owner ou Member. Ces rôles peuvent être soit un rôle de cluster personnalisé intégré, soit un rôle défini par un administrateur Rancher. Ils sont pratiques pour définir un accès restreint ou spécialisé pour un utilisateur standard au sein d’un cluster. Voir le tableau ci-dessous pour une liste des rôles de cluster personnalisés intégrés.

Référence des rôles de cluster

Le tableau suivant répertorie chaque rôle de cluster personnalisé intégré disponible et si ce niveau d’accès est inclus dans les autorisations par défaut au niveau du cluster, Cluster Owner et Cluster Member.

Rôle de cluster intégré Propriétaire Membre

Créer des projets

✓

✓

Gérer les sauvegardes de cluster

✓

Gérer les catalogues de cluster

✓

Gérer les membres du cluster

✓

Gérer les nœuds (voir le tableau ci-dessous)

✓

Gérer le stockage

✓

Voir tous les projets

✓

Voir les catalogues de cluster

✓

✓

Voir les membres du cluster

✓

✓

Voir les nœuds

✓

✓

Gérer les autorisations des nœuds

Le tableau suivant répertorie les autorisations disponibles pour le rôle Manage Nodes dans RKE et RKE2.

Gérer les autorisations des nœuds RKE RKE2

Accès SSH

✓

✓

Supprimer les nœuds

✓

✓

Ajuster la taille des clusters

✓

*

Dans RKE2, vous devez avoir l’autorisation de modifier un cluster pour pouvoir ajuster la taille des clusters.

Pour des détails sur la façon dont chaque rôle de cluster peut accéder aux ressources Kubernetes, vous pouvez les consulter dans l’interface utilisateur de Rancher :

  1. Dans le coin supérieur gauche, cliquez sur ☰ > Utilisateurs et authentification.

  2. Dans la barre de navigation à gauche, cliquez sur Modèles de rôle.

  3. Cliquez sur l’onglet Cluster.

  4. Cliquez sur le nom d’un rôle individuel. Le tableau montre toutes les opérations et ressources autorisées par le rôle.

Lors de la visualisation des ressources associées aux rôles par défaut créés par Rancher, s’il y a plusieurs ressources API Kubernetes sur un même élément de ligne, la ressource aura (Custom) ajoutée à son nom. Ce ne sont pas des ressources personnalisées mais simplement une indication qu’il y a plusieurs ressources API Kubernetes en tant qu’une seule ressource.

Attribuer un rôle de cluster personnalisé à un membre du cluster

Après qu’un administrateur a configuré un rôle de cluster personnalisé, les propriétaires et administrateurs de cluster peuvent alors attribuer ces rôles aux membres du cluster.

Pour attribuer un rôle personnalisé à un nouveau membre du cluster, vous pouvez utiliser l’interface utilisateur de Rancher. Pour modifier les autorisations d’un membre existant, vous devrez utiliser la vue de l’API Rancher.

Pour attribuer le rôle à un nouveau membre du cluster,

  1. Cliquez sur ☰ > Gestion des clusters.

  2. Allez dans le cluster où vous souhaitez attribuer un rôle à un membre et cliquez sur Explorer.

  3. Cliquez sur menu:Cluster[Membres du cluster].

  4. Cliquez sur Ajouter.

  5. Dans la section Permissions du cluster, choisissez le rôle de cluster personnalisé qui doit être attribué au membre.

  6. Cliquez sur Create.

Résultat : Le membre a le rôle attribué.

Pour attribuer un rôle personnalisé à un membre existant du cluster,

  1. Cliquez sur ☰ > Utilisateurs et authentification.

  2. Allez vers le membre à qui vous souhaitez donner le rôle. Cliquez sur le ⋮ > Modifier la configuration.

  3. Si vous avez ajouté des rôles personnalisés, ils apparaîtront dans la section Personnalisé. Choisissez le rôle que vous souhaitez attribuer au membre.

  4. Cliquez sur Enregistrer.

Résultat : Le membre a le rôle attribué.

Rôles de projet

Les rôles de projet sont des rôles qui peuvent être utilisés pour accorder aux utilisateurs l’accès à un projet. Il existe trois rôles principaux dans un projet : Owner, Member et Read Only.

  • Propriétaire de projet :

    Ces utilisateurs ont un contrôle total sur le projet et toutes les ressources qu’il contient.

  • Membre de projet :

    Ces utilisateurs peuvent gérer des ressources spécifiques au projet, comme les espaces de noms et les charges de travail, mais ne peuvent pas gérer d’autres membres du projet.

Par défaut, le rôle Rancher de project-member hérite du rôle Kubernetes-edit, et le rôle project-owner hérite du rôle Kubernetes-admin. Ainsi, les rôles project-member et project-owner permettront la gestion des espaces de noms, y compris la possibilité de créer et de supprimer des espaces de noms.

  • Lecture seule:

    Ces utilisateurs peuvent tout voir dans le projet mais ne peuvent rien créer, mettre à jour ou supprimer.

Les utilisateurs assignés au rôle Owner ou Member pour un projet héritent automatiquement du rôle namespace creation. Cependant, ce rôle est un ClusterRole Kubernetes, ce qui signifie que son champ d’application s’étend à tous les projets du cluster. Par conséquent, les utilisateurs explicitement assignés au rôle owner ou member pour un projet peuvent créer des espaces de noms dans d’autres projets auxquels ils sont assignés, même avec seulement le rôle Read Only assigné.

Rôles de projet personnalisés

Rancher vous permet d’attribuer des rôles de projet personnalisés à un utilisateur standard au lieu des rôles typiques Owner, Member ou Read Only. Ces rôles peuvent être soit un rôle de projet personnalisé intégré, soit un rôle défini par un administrateur Rancher. Ils sont pratiques pour définir un accès restreint ou spécialisé pour un utilisateur standard au sein d’un projet. Voir le tableau ci-dessous pour une liste des rôles de projet personnalisés intégrés.

Référence des rôles de projet

Le tableau suivant répertorie chaque rôle de projet personnalisé intégré disponible dans Rancher et indique s’il est également accordé par le rôle Owner, Member ou Read Only.

Rôle de projet intégré Propriétaire Membre Lecture seule

Gérer les membres du projet

✓

Créer des espaces de noms

✓

✓

Gérer les cartes de configuration

✓

✓

Gérer l’Ingress

✓

✓

Gérer les catalogues de projet

✓

Gérer les secrets

✓

✓

Gérer les comptes de service

✓

✓

Gérer les services

✓

✓

Gérer des volumes

✓

✓

Gérer les charges de travail

✓

✓

Afficher les secrets

✓

✓

Afficher les cartes de configuration

✓

✓

✓

Afficher l’Ingress

✓

✓

✓

Afficher les membres du projet

✓

✓

✓

Afficher les catalogues de projet

✓

✓

✓

Afficher les comptes de service

✓

✓

✓

Afficher les services

✓

✓

✓

Afficher les volumes

✓

✓

✓

Afficher les charges de travail

✓

✓

✓
Remarques :

  • Chaque rôle de projet énuméré ci-dessus, y compris Owner, Member et Read Only, est composé de plusieurs règles accordant l’accès à diverses ressources. Vous pouvez afficher les rôles et leurs règles sur la page Global > Sécurité > Rôles.

  • Lors de la visualisation des ressources associées aux rôles par défaut créés par Rancher, s’il y a plusieurs ressources API Kubernetes sur un même élément de ligne, la ressource aura (Custom) ajoutée à son nom. Ce ne sont pas des ressources personnalisées mais simplement une indication qu’il y a plusieurs ressources API Kubernetes en tant qu’une seule ressource.

  • Le rôle Manage Project Members permet au propriétaire du projet de gérer les membres du projet et de leur attribuer n’importe quel rôle à l’échelle du projet, quel que soit leur accès aux ressources du projet. Soyez prudent lors de l’attribution de ce rôle individuellement.

Définir des rôles personnalisés

Comme mentionné précédemment, des rôles personnalisés peuvent être définis pour une utilisation au niveau du cluster ou du projet. Le champ de contexte définit si le rôle apparaîtra sur la page des membres du cluster, sur la page des membres du projet, ou sur les deux.

Lors de la définition d’un rôle personnalisé, vous pouvez accorder l’accès à des ressources spécifiques ou spécifier des rôles dont le rôle personnalisé doit hériter. Un rôle personnalisé peut être composé d’une combinaison de concessions spécifiques et de rôles hérités. Toutes les concessions sont additives. Cela signifie que définir une concession plus étroite pour une ressource spécifique ne remplacera pas une concession plus large définie dans un rôle dont le rôle personnalisé hérite.

Rôles par défaut de cluster et de projet

Par défaut, lorsqu’un utilisateur standard crée un nouveau cluster ou projet, il se voit automatiquement attribuer un rôle de propriétaire : soit propriétaire de cluster, soit propriétaire de projet. Cependant, dans certaines organisations, ces rôles peuvent étendre excessivement l’accès administratif. Dans ce cas d’utilisation, vous pouvez changer le rôle par défaut pour quelque chose de plus restrictif, comme un ensemble de rôles individuels ou un rôle personnalisé.

Il existe deux méthodes pour changer les rôles par défaut de cluster/projet :

  • Attribuer des rôles personnalisés : Créez un rôle personnalisé pour votre cluster ou votre projet, puis définissez le rôle personnalisé comme par défaut.

  • Attribuer des rôles individuels : Configurez plusieurs rôles cluster/projet par défaut pour l’attribution à l’utilisateur créateur.

    Par exemple, au lieu d’attribuer un rôle qui hérite d’autres rôles (comme cluster owner), vous pouvez choisir un mélange de rôles individuels (comme manage nodes et manage storage).

  • Bien que vous puissiez verrouiller un rôle par défaut, le système attribue toujours le rôle aux utilisateurs qui créent un cluster/projet.

  • Seuls les utilisateurs qui créent des clusters/projets héritent de leurs rôles. Les utilisateurs ajoutés ultérieurement à l’appartenance d’un cluster/projet doivent se voir attribuer explicitement leurs rôles.

Configuration des rôles par défaut pour les créateurs de clusters et de projets

Vous pouvez modifier le(s) rôle(s) de cluster ou de projet qui sont automatiquement attribués à l’utilisateur créateur.

  1. Dans le coin supérieur gauche, cliquez sur ☰ > Utilisateurs et authentification.

  2. Dans la barre de navigation à gauche, cliquez sur Modèles de rôle.

  3. Cliquez sur l’onglet Cluster ou Project/Namespaces.

  4. Trouvez le rôle personnalisé ou individuel que vous souhaitez utiliser par défaut. Puis modifiez le rôle en sélectionnant ⋮ > Modifier la Configuration.

  5. Dans la section Cluster Creator Default ou Project Creator Default, activez le rôle comme par défaut.

  6. Cliquez sur Enregistrer.

Résultat : Les rôles par défaut sont configurés en fonction de vos modifications. Les rôles attribués aux créateurs de clusters/projets affichent une coche dans la colonne Cluster/Project Creator Default.

Si vous souhaitez supprimer un rôle par défaut, modifiez l’autorisation et sélectionnez Non dans l’option des rôles par défaut.

Comportement de révocation de l’appartenance au cluster

Lorsque vous révoquez l’appartenance à la grappe d’un utilisateur standard qui a explicitement reçu l’appartenance à la fois à la grappe et à un projet au sein de la grappe, cet utilisateur standard perd ses rôles de grappe mais conserve ses rôles de projet. En d’autres termes, bien que vous ayez révoqué les autorisations de l’utilisateur pour accéder à la grappe et à ses nœuds, l’utilisateur standard peut toujours :

Si vous souhaitez révoquer complètement l’accès d’un utilisateur au sein d’une grappe, révoquez à la fois son appartenance à la grappe et au projet.

Comportement externe RoleTemplate

Dans Rancher v2.9.0 et versions ultérieures, les objets externes RoleTemplate ne peuvent être créés que si le ClusterRole de support existe dans la grappe locale ou si le ExternalRules est défini dans votre configuration.

Pour contexte, le ClusterRole de support détient les règles et privilèges du cluster, et partage le même metadata.name utilisé dans le RoleTemplate dans votre cluster respectif référencé par le ClusterRoleTemplateBinding/ProjectRoleTemplateBinding. De plus, notez que escalate autorisations sur RoleTemplates sont nécessaires pour créer des RoleTemplates externes avec ExternalRules.