IBM - Basic Information
Hiérarchie
Modèle de ressources IBM Cloud (des docs):
Méthode recommandée pour diviser les projets :
IAM
Utilisateurs
Les utilisateurs ont un email qui leur est attribué. Ils peuvent accéder à la console IBM et également générer des clés API pour utiliser leurs permissions de manière programmatique. Les permissions peuvent être accordées directement à l'utilisateur avec une politique d'accès ou via un groupe d'accès.
Profils de confiance
Ceux-ci sont comme les Rôles d'AWS ou les comptes de service de GCP. Il est possible de les attribuer à des instances VM et d'accéder à leurs identifiants via les métadonnées, ou même permettre aux Fournisseurs d'Identité de les utiliser pour authentifier des utilisateurs de plateformes externes. Les permissions peuvent être accordées directement au profil de confiance avec une politique d'accès ou via un groupe d'accès.
Identifiants de service
C'est une autre option pour permettre aux applications de interagir avec IBM Cloud et d'effectuer des actions. Dans ce cas, au lieu de l'attribuer à une VM ou à un Fournisseur d'Identité, une clé API peut être utilisée pour interagir avec IBM de manière programmatique. Les permissions peuvent être accordées directement à l'identifiant de service avec une politique d'accès ou via un groupe d'accès.
Fournisseurs d'identité
Des Fournisseurs d'Identité externes peuvent être configurés pour accéder aux ressources IBM Cloud depuis des plateformes externes en accédant aux Profils de confiance.
Groupes d'accès
Dans le même groupe d'accès, plusieurs utilisateurs, profils de confiance et identifiants de service peuvent être présents. Chaque principal dans le groupe d'accès héritera des permissions du groupe d'accès. Les permissions peuvent être accordées directement au profil de confiance avec une politique d'accès. Un groupe d'accès ne peut pas être membre d'un autre groupe d'accès.
Rôles
Un rôle est un ensemble de permissions granulaires. Un rôle est dédié à un service, ce qui signifie qu'il ne contiendra que des permissions de ce service. Chaque service de l'IAM aura déjà quelques rôles possibles parmi lesquels choisir pour accorder un accès à un principal à ce service : Visionneuse, Opérateur, Éditeur, Administrateur (bien qu'il puisse y en avoir d'autres).
Les permissions de rôle sont données via des politiques d'accès aux principaux, donc si vous devez donner par exemple une combinaison de permissions d'un service de Visionneuse et Administrateur, au lieu de donner ces 2 (et de sur-privilégier un principal), vous pouvez créer un nouveau rôle pour le service et donner à ce nouveau rôle les permissions granulaires dont vous avez besoin.
Politiques d'accès
Les politiques d'accès permettent de joindre 1 ou plusieurs rôles d'un service à 1 principal. Lors de la création de la politique, vous devez choisir :
Le service où les permissions seront accordées
Ressources concernées
Accès Service & Plateforme qui sera accordé
Ceux-ci indiquent les permissions qui seront données au principal pour effectuer des actions. Si un rôle personnalisé est créé dans le service, vous pourrez également le choisir ici.
Conditions (le cas échéant) pour accorder les permissions
Pour accorder l'accès à plusieurs services à un utilisateur, vous pouvez générer plusieurs politiques d'accès
Références
Last updated
