# IBM - Basic Information

{{#include ../../banners/hacktricks-training.md}}

## Hierarchy

IBM Cloud resource model ([from the docs](https://www.ibm.com/blog/announcement/introducing-ibm-cloud-enterprises/)):

<figure><img src="../../images/image (225).png" alt=""><figcaption></figcaption></figure>

Recommended way to divide projects:

<figure><img src="../../images/image (239).png" alt=""><figcaption></figcaption></figure>

## IAM

<figure><img src="../../images/image (266).png" alt=""><figcaption></figcaption></figure>

### Users

Users have an **email** assigned to them. They can access the **IBM console** and also **generate API keys** to use their permissions programatically.\
**Permissions** can be granted **directly** to the user with an access policy or via an **access group**.

### Trusted Profiles

These are **like the Roles of AWS** or service accounts from GCP. It's possible to **assign them to VM** instances and access their **credentials via metadata**, or even **allow Identity Providers** to use them in order to authenticate users from external platforms.\
**Permissions** can be granted **directly** to the trusted profile with an access policy or via an **access group**.

### Service IDs

This is another option to allow applications to **interact with IBM cloud** and perform actions. In this case, instead of assign it to a VM or Identity Provider an **API Key can be used** to interact with IBM in a **programatic** way.\
**Permissions** can be granted **directly** to the service id with an access policy or via an **access group**.

### Identity Providers

External **Identity Providers** can be configured to **access IBM cloud** resources from external platforms by accessing **trusting Trusted Profiles**.

### Access Groups

In the same access group **several users, trusted profiles & service ids** can be present. Each principal in the access group will **inherit the access group permissions**.\
**Permissions** can be granted **directly** to the trusted profile with an access policy.\
An **access group cannot be a member** of another access group.

### Roles

A role is a **set of granular permissions**. **A role** is dedicated to **a service**, meaning that it will only contain permissions of that service.\
**Each service** of IAM will already have some **possible roles** to choose from to **grant a principal access to that service**: **Viewer, Operator, Editor, Administrator** (although there could be more).

Role permissions are given via access policies to principals, so if you need to give for example a **combination of permissions** of a service of **Viewer** and **Administrator**, instead of giving those 2 (and overprivilege a principal), you can **create a new role** for the service and give that new role the **granular permissions you need**.

### Access Policies

Access policies allows to **attach 1 or more roles of 1 service to 1 principal**.\
When creating the policy you need to choose:

- The **service** where permissions will be granted
- **Affected resources**
- Service & Platform **access** that will be granted
  - These indicate the **permissions** that will be given to the principal to perform actions. If any **custom role** is created in the service you will also be able to choose it here.
- **Conditions** (if any) to grant the permissions

> [!NOTE]
> To grant access to several services to a user, you can generate several access policies

<figure><img src="../../images/image (248).png" alt=""><figcaption></figcaption></figure>

## References

- [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}}



