Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
IBM Cloud resource model (from the docs):
Recommended way to divide projects:
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.
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.
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.
External Identity Providers can be configured to access IBM cloud resources from external platforms by accessing trusting Trusted Profiles.
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.
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 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
To grant access to several services to a user, you can generate several access policies
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
