IBM Cloud Docs
Access management in IBM Cloud

Access management in IBM Cloud

After deciding how to organize your accounts and resources, you will need to properly manage access for deployments of the reference architectures that will help achieve separation of duties and least privilege.

Managing access with access groups

An access group is a grouping of user and service IDs to which the same IAM access can be granted. You can assign a single policy to the group instead of assigning the same access multiple times per individual user or service ID. A logical way to assign access is by creating one access group per wanted level of access.

Always use access groups for managing access. IAM policies should never be attached directly to users.

For more information:

You must determine what set of access groups works well for your situation. Whatever structure you choose, repeat it for every account (whether a stand-alone account or part of an enterprise).

Example access group structure

For illustration, the following table shows one possible setup that provides for a reasonable separation of duties.

Table 1. Access groups
Access Group Description
cloud-organization-admins Responsible for organizing the structure of the resources used by the organization.
cloud-network-admins Responsible for creating networks, VPCs, load balancers, subnets, firewall rules, and network devices.
cloud-security-admins Responsible for establishing and managing security policies for the entire organization, including access management and organization constraint policies.
cloud-billing-admins Responsible for setting up billing accounts and monitoring their usage.
cloud-devops DevOps practitioners create or manage end-to-end pipelines that support continuous integration and delivery, monitoring, and system provisioning.
cloud-developers Developers are responsible for designing, coding, and testing applications.

After the access groups are created, you can assign roles to them.

Never assign roles directly to users. Assign roles to access groups only.

For more information, see:

Invite users to your account

After you have access groups in place, then you can start inviting users to your account and assigning them to the appropriate access group depending on their job responsibilities. For more information, see Inviting users to an account.

Access groups with dynamic rules

If you're using an external identity provider, dynamic rules allow you to automatically add federated users to an access group based on SAML assertions. When a user logs in with a federated ID, the data that is provided by your identity provider dynamically maps the user to an access group based on the rules that you set. This can dramatically ease the administration of your account.

For more information see:

  1. Creating dynamic rules for access groups
  2. Control access to cloud resources - See the section "Background information about access groups and dynamic rules"

Considerations for enterprises

If you're using an enterprise, these resources provide additional information:

Required permissions for services in reference architecture

The following table provides references to additional information for managing access with IAM for each service in the reference architectures.

Table 1. Managing access for IBM Cloud services in the reference architectures
Category VPC reference architecture Satellite reference architecture Optional for both
Core
Containers
Networking
Storage
Security
Logging and monitoring
Integration

Next steps

  1. Includes VPC, Dedicated hosts for VPC, Auto Scale for VPC, Application Load Balancer for VPC, VPN for VPC, DNS Services, and VPE for VPC. ↩︎

  2. Satellite-enabled service which runs in your Satellite location. ↩︎