Identity and Access Management in IBM Cloud
Subjects, targets, roles
IAM policies bind a subject (user, service ID, access group, trusted profile) to a target (account, resource group, resource type, or specific resource) with a role. Platform roles are Viewer, Operator, Editor, Administrator; service roles include Reader, Writer, Manager, and service-specific ones. Administrator includes managing access; Editor can create and modify but cannot grant.
Machine identity
Service IDs represent applications; API keys authenticate as a subject and inherit, but never exceed, that subject's policies. Trusted profiles let compute resources such as VPC instances, Red Hat OpenShift on IBM Cloud clusters, or Code Engine apps obtain tokens through compute resource identity instead of embedding secrets. Service-to-service calls should use authorization policies between source and target services.
Conditions
Context-based restrictions add an authorization condition based on network zones and rules for IAM-enabled service endpoints. IAM tokens are short-lived (about 60 minutes); API keys persist until rotated or deleted, so rotation is an incident-response lever.
Worked example
An OpenShift workload must read one COS bucket. Create a service ID for the workload, add it to an access group holding Writer on that bucket only, and add an authorization policy from Kubernetes Service to Cloud Object Storage so the cluster can mint credentials. Do not attach account-level Administrator to the service ID.
Traps that cost marks
Policies on a resource group apply to everything later added to it. An API key is capped by its owner's access, so a key does not escalate privilege. Viewer lets you see a resource but not necessarily enumerate all lists. Deleting a user's policies does not revoke an existing API key automatically.