IBM - Basic Information
Hiérarchie
Modèle de ressources IBM Cloud (à partir de la documentation) :
Façon recommandée de diviser les projets :
IAM
Utilisateurs
Les utilisateurs ont un e-mail qui leur est attribué. Ils peuvent accéder à la console IBM et également générer des clés API pour utiliser leurs autorisations de manière programmatique. Les autorisations 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 informations d'identification via les métadonnées, ou même de permettre aux fournisseurs d'identité de les utiliser pour authentifier les utilisateurs à partir de plates-formes externes. Les autorisations 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
Il s'agit d'une autre option permettant aux applications d'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 autorisations 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 à partir de plates-formes externes en accédant à des 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 autorisations du groupe d'accès. Les autorisations 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 d'autorisations granulaires. Un rôle est dédié à un service, ce qui signifie qu'il ne contiendra que les autorisations de ce service. Chaque service de l'IAM aura déjà quelques rôles possibles à choisir pour accorder à un principal l'accès à ce service : Viewer, Operator, Editor, Administrator (bien qu'il puisse y en avoir plus).
Les autorisations de rôle sont données via des politiques d'accès aux principaux, donc si vous devez donner par exemple une combinaison d'autorisations d'un service de Viewer et Administrateur, au lieu de donner ces 2 (et sur-privilegier un principal), vous pouvez créer un nouveau rôle pour le service et donner à ce nouveau rôle les autorisations granulaires dont vous avez besoin.
Politiques d'accès
Les politiques d'accès permettent de attacher 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 autorisations seront accordées
Ressources affectées
Accès au service et à la plateforme qui sera accordé
Cela indique les autorisations 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 autorisations
Pour accorder l'accès à plusieurs services à un utilisateur, vous pouvez générer plusieurs politiques d'accès
Références
Dernière mise à jour
