Rôles et actions IAM

Red Hat OpenShift on IBM Cloud est configuré pour utiliser les rôles IBM Cloud® Identity and Access Management afin de déterminer les actions que les utilisateurs peuvent effectuer sur les clusters Red Hat OpenShift on IBM Cloud, les nœuds de travail et les équilibreurs de charge d'application (ALB) Ingress.

Consultez le tableau suivant pour obtenir la liste des rôles de plateforme et de service et des actions associées.

Pour une liste de tous les services IBM et des rôles et actions qui leur sont associés, voir Rôles et actions IAM. Pour plus d'informations sur la configuration de votre compte et de vos ressources, voir Pratiques recommandées pour l'organisation des utilisateurs, des équipes et des applications.

Rôles d'accès à la plateforme: Avec les rôles d'accès à la plateforme, les utilisateurs peuvent gérer des ressources telles que des clusters, des pools de noeuds worker, des noeuds worker et des modules complémentaires. Exemples d'actions autorisées par les rôles d'accès à la plateforme : création ou retrait de clusters, liaison de services à un cluster, gestion des réseaux et des ressources de stockage ou ajout de noeuds worker supplémentaires. Vous pouvez définir des règles pour ces rôles par groupe de ressources, région ou instance de cluster. Vous ne pouvez pas étendre un rôle d'accès de plateforme par espace de nom au sein d'un cluster. Les rôles d'accès à la plateforme n'accordent pas d'accès à l'API Kubernetes pour gérer les ressources au sein du cluster, comme les gousses Kubernetes, les espaces de nom ou les services.
Rôles d'accès au service: Utilisez des rôles d'accès au service pour permettre aux utilisateurs de gérer des ressources Kubernetes dans des clusters Red Hat OpenShift on IBM Cloud. Les rôles d'accès aux services sont synchronisés avec les « Kubernetes Politiques RBAC » correspondants au sein d'un cluster. À ce titre, les rôles d'accès aux services permettent d'accéder à l'API Kubernetes, au tableau de bord et à l'interface de ligne de commande (oc). Parmi les actions autorisées par ces rôles d'accès aux services, on peut citer la création de déploiements d'applications, l'ajout d'espaces de noms ou la configuration de cartes de configuration. Vous pouvez définir la portée de la règle pour les rôles d'accès au service par groupe de ressources, région ou instance de cluster. En outre, vous pouvez également étendre les rôles d'accès au service aux espaces de nom Kubernetes qui se trouvent dans tous les clusters, les clusters individuels ou les clusters d'une région spécifique.

Droits de création d'un cluster

Passez en revue les droits suivants dont vous avez besoin pour créer un cluster, y compris les droits requis pour d'autres intégrations et services que vous pouvez utiliser.

Rôles IAM requis pour créer un cluster.
Service ou groupe de ressources	Rôle	Portée	Obligatoire ?
Kubernetes Service	-rôle d'accès à la plateforme Administrateur -rôle d'accès au service Auteur ou Responsable	Groupe de ressources dans lequel vous souhaitez créer un cluster.	Oui
Container Registry	Rôle d'accès à la plateforme d'administration.	Une instance individuelle ou toutes les instances. Ne limitez pas les règles d'IBM Cloud Container Registry au niveau du groupe de ressources.	Oui
IBM Cloud Object Storage	Rôle d'accès à la plateforme d'administration	Une instance individuelle ou toutes les instances.	Oui
Secrets Manager	Rôle d'accès à la plateforme ou Editeur -Rôle d'accès au service Responsable	Tous les groupes de ressources	Obligatoire si vous prévoyez d'utiliser Secrets Manager pour le chiffrement.
Droits relatifs à un groupe de ressources	Rôle d'accès à la plateforme de visualisation	Groupe de ressources dans lequel vous souhaitez créer un cluster.	Oui
IAM Identity Service	Créateur d'ID de service Rôle de créateur de clé d'API utilisateur -Rôle d'accès à la plateforme Afficheur	Groupe de ressources dans lequel vous souhaitez créer un cluster.	Oui
Key Protect	Rôle d'accès à la plateforme d'administration.	Toutes les instances ou l'instance spécifique que vous souhaitez utiliser.	Obligatoire si vous prévoyez d'utiliser Key Protect pour le chiffrement.
Hyper Protect Crypto Services	Rôle d'accès à la plateforme d'administration.	Toutes les instances ou l'instance spécifique que vous souhaitez utiliser.	Obligatoire si vous prévoyez d'utiliser Hyper Protect Crypto Services pour le chiffrement.
Infrastructure classique	Rôle Superutilisateur. Pour plus d'informations, voir Rôles d'infrastructure classique.	N/A	Oui
Infrastructure de cloud privé virtuel	Rôle d'accès à la plateforme d'administration pour l'infrastructure VPC.	Toutes les instances ou l'instance spécifique que vous souhaitez utiliser.	Oui

Pensez à sauvegarder les droits décrits dans le tableau précédent en tant que rôle IAM personnalisé. Ainsi, vous pouvez affecter des utilisateurs au rôle personnalisé au lieu d'affecter chaque service individuel. Pour plus d'informations, voir les exemples de rôles personnalisés suivants ou la documentation IAM relative à la création de rôles personnalisés.

Exemples de rôles IAM personnalisés

Le tableau suivant présente des exemples de cas d'utilisation et les rôles IAM correspondants. Vous pouvez utiliser ces exemples ou créer vos propres rôles personnalisés. Pour plus d'informations, voir Création de rôles personnalisés.

Types de rôle que vous pouvez affecter en réponse à différents cas d'utilisation.
Exemple de rôle personnalisé	Droits
Auditeur d'application	Rôle d'accès « Viewer » à la plateforme pour un cluster, une région ou un groupe de ressources. Rôle d'accès « Reader » au service pour un cluster, une région ou un groupe de ressources.
Développeurs d'applications	-Rôle d'accès à la plateforme de l'éditeur pour un cluster. -Rôle d'accès au service de l'éditeur sectorisé à un espace de nom.
Facturation	Rôle d'accès à la plateforme Viewer pour un cluster, une région ou un groupe de ressources.
Administrateur de cluster	-Rôle d'accès à la plateforme Administrateur pour un cluster. -Rôle d'accès au service Responsable pour l'ensemble du cluster (non sectorisé à un espace de nom).
Opérateur DevOps	-Rôle d'accès à la plateforme Opérateur pour un cluster. -Rôle d'accès au service Auteur pour l'ensemble du cluster (non sectorisé à un espace de nom).
Opérateur ou ingénieur SRE	Rôle d'accès « Administrateur » à la plateforme pour un cluster, une région ou un groupe de ressources. Rôle d'accès « Lecteur » au service pour un cluster ou une région. Rôle d'accès « Gestionnaire » au service pour tous les espaces de noms du cluster afin de pouvoir utiliser les commandes `kubectl top nodes,pods`.

Rôles d'infrastructure classique

Un utilisateur disposant du rôle d'accès « Super User » à l'infrastructure configure la clé API pour une région et un groupe de ressources afin de permettre l'exécution d'actions sur l'infrastructure.

Les actions liées à l'infrastructure que les autres utilisateurs du compte peuvent effectuer sont autorisées via les rôles d'accès de la plateforme IAM d' IBM Cloud.

Utilisez le tableau suivant pour personnaliser les autorisations de l'infrastructure classique uniquement lorsque vous ne pouvez pas attribuer le rôle « Super utilisateur » à l'utilisateur qui configure la clé API. Pour en savoir plus sur l'affectation de droits, voir Personnalisation des droits d'infrastructure.

Droits d'infrastructure classique requis

Tableau 1: Droits d'infrastructure classique requis
Droit	Description
Gestion à distance IPMI	Gérer des noeuds worker.
Ajouter un serveur	Ajouter des noeuds worker. Remarque : Pour les noeuds worker ayant des adresses IP publiques, vous devez également disposer du droit Ajouter la fonction de calcul avec le port réseau public de la catégorie réseau.
Annuler un serveur	Supprimer des noeuds worker.
Rechargements de SE et noyau de secours	Mettre à jour, réamorcer et recharger des noeuds worker.
Afficher les détails du serveur virtuel	Requis si le cluster comporte des noeuds worker de machine virtuelle. Répertorier et obtenir des détails de noeuds worker de machine virtuelle.
Afficher des détails du matériel	Requis si le cluster comporte des noeuds worker bare metal. Répertorier et obtenir des détails de noeuds worker bare metal.
Ajouter un cas de support	Dans le cadre de l'automatisation de la création de cluster, des cas de support sont ouverts pour mettre à disposition l'infrastructure de cluster.
Editer un cas de support	Dans le cadre de l'automatisation de la création de cluster, des cas de support sont mis à jour pour mettre à disposition l'infrastructure de cluster.
Afficher un cas de support	Dans le cadre de l'automatisation de la création de cluster, des cas de support sont utilisés pour mettre à disposition l'infrastructure de cluster.

Droits d'infrastructure classique suggérés

Tableau 2: Droits d'infrastructure classique suggérés
Droit	Description
Accès automatique au serveur virtuel	Accédez à tous les noeuds worker.
Accès automatique au serveur bare metal	Concevoir l'accès à tous les noeuds worker bare metal. Sans ce droit, il se peut qu'un utilisateur qui crée un cluster ne puisse pas visualiser les noeuds worker bare metal d'un autre cluster même si l'utilisateur dispose d'un accès IAM aux deux clusters.
Ajouter la fonction de calcul avec le port réseau public	Permettre aux noeuds worker de disposer d'un port qui peut être accessible sur le réseau public.
Gérer DNS	Configurer un équilibreur de charge public ou un réseau Ingress pour exposer des applications.
Editer le nom d'hôte/domaine	Configurer un équilibreur de charge public ou un réseau Ingress pour exposer des applications.
Ajouter des adresses IP	Ajouter des adresses IP aux sous-réseaux publics ou privés qui sont utilisés pour l'équilibrage de charge de cluster.
Gérer les routes de sous-réseau du réseau	Gérer des VLAN publics ou privés qui sont utilisés pour l'équilibrage de charge de cluster.
Gérer le contrôle de port	Gérer des ports qui sont utilisés pour l'équilibrage de charge d'application.
Gérer les certificats (SSL)	Configurer des certificats qui sont utilisés pour l'équilibrage de charge de cluster.
Afficher les certificats (SSL)	Configurer des certificats qui sont utilisés pour l'équilibrage de charge de cluster.
Ajouter/Mettre à niveau du stockage (couche de stockage)	Créer des instances de stockage de fichiers ou par blocs IBM Cloud à associer en tant que volumes à vos applications pour le stockage persistant de données.
Gestion de stockage	Gérer des instances de stockage de fichiers ou par blocs IBM Cloud qui sont associées en tant que volumes à vos applications pour le stockage persistant de données.