# IBM - Informations de base {{#include ../../banners/hacktricks-training.md}} ## Hiérarchie Modèle de ressources IBM Cloud ([des docs](https://www.ibm.com/blog/announcement/introducing-ibm-cloud-enterprises/)):
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 Ce 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 provenant 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 à **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 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 affectées** - Accès au service et à la plateforme **qui sera accordé** - Cela indique 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 > [!NOTE] > Pour accorder l'accès à plusieurs services à un utilisateur, vous pouvez générer plusieurs politiques d'accès
## Références - [https://www.ibm.com/cloud/blog/announcements/introducing-ibm-cloud-enterprises](https://www.ibm.com/cloud/blog/announcements/introducing-ibm-cloud-enterprises) - [https://cloud.ibm.com/docs/account?topic=account-iamoverview](https://cloud.ibm.com/docs/account?topic=account-iamoverview) {{#include ../../banners/hacktricks-training.md}}