IBM Cloud Resource Groups and IAM: A Practical Orientation

The shape of an IBM Cloud account

IBM Cloud rewards a few minutes of orientation because it carries more history than most platforms. Two distinct generations of infrastructure live under one console, and the access model that governs one of them does not fully govern the other. Knowing that in advance turns a confusing first week into a straightforward one.

At the top is the account. Accounts come in several types, from a limited entry account through pay-as-you-go and subscription arrangements up to an enterprise account, which can own a hierarchy of account groups and child accounts for organisations that need separate billing units under one roof.

Inside an account, work is organised into resource groups. Above and across everything sits IBM Cloud IAM, which decides who may do what and where. Those two ideas, resource groups and IAM, carry almost all of the day-to-day weight, so the rest of this guide concentrates on them.

Resource groups, and the rule that catches everyone

A resource group is a container for service instances. Every account starts with one named Default, and you can create more to separate environments, teams or applications. Access policies and usage reporting can both be scoped to a resource group, which is what makes them worth using deliberately.

Now the rule that catches people out. For most services, the resource group is chosen when an instance is created and cannot be changed afterwards. There is no casual drag between groups; correcting a mistake generally means provisioning a new instance in the right place and migrating to it.

That single constraint should shape your first decisions. Agree a naming scheme and a group layout before anyone provisions anything, because the cost of getting it wrong is measured in migrations rather than clicks. A simple and durable pattern is one group per environment, with shared platform services in a group of their own.

Resource groups are not billing boundaries in the way an account is. Charges roll up to the account, and the resource group appears as an attribute you can filter on in usage reports. If you need genuinely separate invoices, that is a job for separate accounts under an enterprise hierarchy, a distinction explored more generally in what a cloud account is.

The classic infrastructure exception

IBM Cloud inherited an earlier infrastructure platform, and its resources are still referred to as classic infrastructure: classic virtual servers, classic bare metal, classic file and block storage, and the network constructs that go with them. These predate the current resource and IAM model.

The practical consequence is that classic resources are not placed in resource groups and are not governed by the same IAM policies. They use a separate classic infrastructure permission set, granted per user, with its own device access lists. A user can therefore have generous IAM permissions and still be unable to see a classic bare metal server, or the reverse.

Newer services, including Virtual Private Cloud infrastructure, Kubernetes Service, Code Engine, Object Storage and the database portfolio, sit fully inside the resource group and IAM model. Where you have a choice, choosing the VPC generation keeps your access model in one place instead of two.

When you audit permissions, remember to audit both systems. A review that only reads IAM policies is incomplete on an account that still runs classic resources.

How access is actually granted

An IBM Cloud access policy has three parts: a subject, a set of roles and a scope. The subject is a user, a service ID, a trusted profile or, preferably, an access group. The scope can be the whole account, a resource group, a service across the account, or one specific service instance.

Roles come in two families, and confusing them is the most common source of a puzzling permission denial. Platform roles govern management operations such as creating, deleting and assigning access. Service roles govern operations inside a service, such as reading objects in a bucket.

A user who can create a database but cannot read from it usually has an Editor platform role with no service role attached. A user who can read objects but cannot see the bucket in the resource list usually has the reverse. Grant both families when someone needs to use what they create.

Assign policies to access groups rather than to individuals. An access group is a named bundle of policies that people are added to and removed from, which turns onboarding into a single membership change. The underlying reasoning is the least-privilege argument set out in cloud IAM fundamentals.

Identities that are not people

Automation needs credentials too, and IBM Cloud offers three mechanisms with different lifetimes and risks.

A service ID is an identity for an application or a pipeline. It receives policies exactly as a user does, and it can hold one or more API keys. Because a service ID is not tied to an employee, it survives staff changes cleanly, which is the main reason to prefer it over a personal API key in any shared automation.

An API key is a long-lived secret. It is shown once at creation and cannot be retrieved later, so it belongs in a secret manager rather than in a repository or a chat message. Rotate keys on a schedule and delete the ones nobody can account for, following the practices in managing API keys and secrets.

A trusted profile is the modern alternative and generally the better one. Instead of holding a static secret, a trusted profile grants access based on an identity the platform can verify, such as a compute resource in your account or a federated identity from an external provider. Fewer secrets in circulation means fewer secrets to leak.

Layer context-based restrictions on top where the data warrants it. These constrain access to a service by network location or endpoint type, so a stolen key alone is not sufficient.

A first session with the ibmcloud CLI

The command line makes the account structure visible quickly. Log in, choose a region, then set the resource group you intend to work in so that later commands do not need to be told each time:

ibmcloud login --sso -r eu-de

ibmcloud resource groups

ibmcloud target -g Production

List what already exists, then inspect the access model behind it:

ibmcloud resource service-instances

ibmcloud iam access-groups

ibmcloud iam access-group-policies Developers

Creating a scoped policy from the command line is a single statement, and writing it out is a good way to internalise the subject, roles and scope triple:

ibmcloud iam access-group-policy-create Developers --roles Editor,Writer --resource-group-name NonProd

IBM publishes the full command reference and the underlying concepts in its IAM roles documentation, which is the authoritative place to check exactly which role a given service action requires.

Key takeaways

• Decide the resource group layout before provisioning, because most services cannot be moved between groups afterwards.
• Classic infrastructure uses a separate permission system. Audit both it and IAM, or prefer VPC generation resources to keep access in one model.
• Platform roles and service roles are different families. Most mysterious permission errors are a missing role from the other family.
• Assign policies to access groups, never to individuals, so joiners and leavers are a membership change.
• Prefer trusted profiles over long-lived API keys, and store any key that must exist in a secret manager.

For how IBM Cloud compares with the platforms it is most often weighed against, see the AWS and IBM Cloud comparison and the IBM Cloud and Oracle Cloud comparison. The IBM Cloud account listings describe the options available through the marketplace.