Skip to content

Latest commit

 

History

History
99 lines (62 loc) · 6.06 KB

ibm-basic-information.md

File metadata and controls

99 lines (62 loc) · 6.06 KB
Raw

IBM - Basic Information

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Hierarchy

IBM Cloud resource model (from the docs):

Recommended way to divide projects:

IAM

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

{% hint style="info" %} To grant access to several services to a user, you can generate several access policies {% endhint %}

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}