IBM Cloud IAM & Access Management

IBM Cloud IAM Overview

IBM Cloud Identity and Access Management (IAM) provides a unified framework for controlling who can access which resources and what actions they can perform. Unlike some cloud providers that separate identity management from access control, IBM Cloud IAM combines both into a single service that manages users, service IDs, access groups, trusted profiles, API keys, and fine-grained access policies across all IBM Cloud services.

IBM Cloud IAM uses an attribute-based access control (ABAC) model built on the XACML standard, which is more flexible than the simple RBAC models used by some competitors. Access policies define a subject (who), a target (which resource), and roles (what actions). The subject can be a user, a service ID, an access group, or a trusted profile. The target can be as broad as an entire account or as specific as a single resource instance. Roles come in two types: platform roles that control infrastructure management actions and service roles that control data-plane actions specific to each service.

This guide covers the core IAM concepts, best practices for access group design, service ID management, trusted profiles for cross-account access, API key governance, and integrating IBM Cloud IAM with external identity providers through SAML federation.

Core IAM Concepts

Users and Invitations

Users in IBM Cloud are identified by their IBMid, which is a universal IBM identity used across all IBM products and services. To grant someone access to your IBM Cloud account, you invite them using their email address. The invitation triggers an IBMid creation if they do not already have one. Once a user accepts the invitation and joins the account, you can assign them to access groups and grant individual policies.

# Invite a user to the account
ibmcloud account user-invite user@example.com

# List all users in the account
ibmcloud account users

# Remove a user from the account
ibmcloud account user-remove user@example.com --force

Access Groups

Access groups are the recommended way to manage access in IBM Cloud. An access group is a collection of users and service IDs that share the same access policies. Instead of assigning policies to individual users, you add users to access groups and assign policies to the groups. This simplifies access management significantly, especially in large organizations where employees join and leave teams frequently.

# Create an access group
ibmcloud iam access-group-create dev-team \
  --description "Development team with access to dev resources"

# Add a user to the access group
ibmcloud iam access-group-user-add dev-team user@example.com

# Add a service ID to the access group
ibmcloud iam access-group-service-id-add dev-team ServiceId-xxxx

# List access groups
ibmcloud iam access-groups

# List members of an access group
ibmcloud iam access-group-users dev-team

Dynamic Rules for Access Groups

Dynamic rules automatically add users to access groups based on identity attributes from your federated identity provider. For example, you can create a rule that adds all users with a specific department claim from your SAML IdP to the "dev-team" access group. This eliminates the need to manually manage group membership when users change roles.

# Create a dynamic rule for federated users
ibmcloud iam access-group-rule-create dev-team \
  --name "auto-add-developers" \
  --expiration 24 \
  --realm-name "https://idp.example.com" \
  --conditions "claim:department,equals,engineering"

Access Policies

Access policies are the core mechanism for granting permissions in IBM Cloud. Each policy defines who can do what on which resources. Policies can target resources at multiple levels of specificity:

• All resources in the account: Broad access for administrators.
• All resources in a resource group: Environment-level access.
• All instances of a specific service: Service-level access.
• A specific service instance: Instance-level access.
• A resource type within an instance: Fine-grained access (e.g., a specific COS bucket).

# Grant Editor role on all resources in a resource group
ibmcloud iam access-group-policy-create dev-team \
  --roles Editor \
  --resource-group-name dev-resources

# Grant Writer role on a specific COS instance
ibmcloud iam access-group-policy-create dev-team \
  --roles Writer \
  --service-name cloud-object-storage \
  --service-instance <cos-instance-id>

# Grant Viewer role on all VPC resources
ibmcloud iam access-group-policy-create dev-team \
  --roles Viewer \
  --service-name is

# List policies for an access group
ibmcloud iam access-group-policies dev-team

Platform Roles vs Service Roles

IBM Cloud IAM distinguishes between platform roles and service roles. Platform roles control management actions that apply across all services — creating instances, binding services, managing access, viewing billing. Service roles control data-plane actions specific to each service — reading and writing objects in COS, querying databases, invoking functions.

The standard platform roles are:

• Viewer: View instances and resources but cannot modify them.
• Operator: View and manage instances (start, stop, restart).
• Editor: All Operator actions plus create, modify, and delete resources.
• Administrator: All Editor actions plus manage access policies.

Service roles vary by service but commonly include:

• Reader: Read-only access to service data.
• Writer: Read and write access to service data.
• Manager: Full access to service data and configuration.

Service IDs and API Keys

Service IDs are identities for applications and services that need programmatic access to IBM Cloud resources. Unlike user identities (IBMids), service IDs are not tied to a person and can have their own API keys and access policies. Every application that interacts with IBM Cloud APIs should use a service ID rather than a personal API key.

# Create a service ID
ibmcloud iam service-id-create my-app-service \
  --description "Service ID for production application"

# Create an API key for the service ID
ibmcloud iam service-api-key-create my-app-key my-app-service \
  --description "Production API key" \
  --file my-app-key.json

# Lock the API key to prevent deletion
ibmcloud iam service-api-key-lock my-app-key my-app-service

# Assign a policy to the service ID
ibmcloud iam service-policy-create my-app-service \
  --roles Writer \
  --service-name cloud-object-storage \
  --service-instance <cos-instance-id>

Trusted Profiles

Trusted profiles provide a way to grant access to IBM Cloud resources without creating permanent credentials. They are particularly useful for compute resources (virtual servers, Kubernetes pods, Code Engine jobs) that need to access IBM Cloud services without storing API keys. Trusted profiles use identity tokens that are automatically injected into the compute environment and expire after a configurable period.

Trusted profiles can also be used for federated users from external identity providers. Instead of inviting each user individually, you create a trusted profile with conditions based on SAML or OIDC claims, and any user from the federated IdP who matches the conditions can assume the profile and access IBM Cloud resources.

# Create a trusted profile for compute resources
ibmcloud iam trusted-profile-create prod-app-profile \
  --description "Profile for production app instances"

# Create a trust policy for IKS cluster
ibmcloud iam trusted-profile-rule-create prod-app-profile \
  --name "iks-pods" \
  --type "Profile-CR" \
  --conditions "claim:namespace,equals,production" \
  --cr-type "IKS_SA"

# Assign access policies to the trusted profile
ibmcloud iam trusted-profile-policy-create prod-app-profile \
  --roles Writer \
  --service-name cloud-object-storage

SAML Federation

IBM Cloud supports SAML 2.0 federation, allowing users to authenticate with their corporate identity provider (such as Microsoft Entra ID, Okta, PingFederate, or ADFS) and access IBM Cloud resources without creating separate IBMids. Federation is configured at the account level and requires an administrator to set up the SAML identity provider in the IBM Cloud IAM settings.

When federation is configured, users navigate to the IBM Cloud login page, enter their email address, and are redirected to their corporate identity provider for authentication. After successful authentication, the IdP sends SAML assertions back to IBM Cloud, which maps the user to the appropriate access groups based on dynamic rules.

Context-Based Restrictions

Context-based restrictions (CBR) add an additional layer of access control by limiting where API calls can originate from. Even if a user or service ID has the correct IAM policies, CBR can deny the request if it does not come from an allowed network context (such as a specific VPC, a set of IP addresses, or a particular service).

# Create a network zone
ibmcloud cbr zone-create \
  --name "corporate-network" \
  --description "Corporate VPN and office IPs" \
  --addresses "203.0.113.0/24,198.51.100.0/24"

# Create a rule restricting COS access to the zone
ibmcloud cbr rule-create \
  --description "Restrict COS to corporate network" \
  --service-name cloud-object-storage \
  --zone-id <zone-id> \
  --enforcement-mode "enabled"

IAM Audit and Compliance

All IAM actions in IBM Cloud are logged in Activity Tracker, providing a complete audit trail of who accessed what resources and when. Common IAM events to monitor include policy changes, user invitations, API key creation and deletion, login events, and access group modifications.

IBM Cloud Security and Compliance Center can continuously evaluate your IAM configuration against predefined or custom compliance profiles, alerting you to deviations such as users with overly broad access, API keys that have not been rotated, or access groups without multi-factor authentication requirements.

Best Practices Summary

• Use access groups for all access management; avoid assigning policies to individual users.
• Follow the principle of least privilege: grant the minimum roles needed for each job function.
• Use service IDs for all programmatic access; never share personal API keys with applications.
• Enable MFA at the account level for all users.
• Use trusted profiles for compute workloads to avoid storing long-lived credentials.
• Implement context-based restrictions for sensitive services.
• Regularly review access policies and remove stale access.
• Use dynamic rules to automate access group membership for federated users.
• Lock production API keys to prevent accidental deletion.
• Monitor all IAM events in Activity Tracker and set up alerts for critical changes.