Identity and Access Management(IAM) in IBM Cloud

6 min readJun 28, 2020

Introduction

With the advent of cloud computing and cloud-native development, there is a growing need for a secure and granular mechanism to authenticate and authorize users with platform services. Adding users to the cloud helps them to authenticate with the account and adding them in specific Role-Based Access Controls(RBAC) group, enables them to authorize and access the various services. IBM Cloud has a number of RBAC that help in authorizing users and control their access across the numerous services on the platform. The three different types of RBAC controls that cover all the resources are Cloud Foundry, Classic infrastructure permissions and IAM. We will go over each of these in the following sections.

Access to Cloud Foundry

Cloud Foundry is an open-source platform as a service(PaaS) offering by IBM Cloud that supports deployment of cloud-native applications. Access to Cloud Foundry resources is provided using Organizations and Spaces.

The diagram explains how an organization groups different spaces and its typical use case. An organization is created for your project. It will have spaces according to the different environments of your project(i.e. production, stage and development). Users are granted access to organisations and the spaces where they need to work on. A user can be granted a number of roles at organization as well as space level.

Organization level roles:

Manager : Add, Delete, Modify spaces within organisation. Manage user access to the organization and spaces, view usage and quota information.
Billing Manager : Can view runtime and service usage information for the organization on the Usage page.
Auditor : Viewer access to organization services, users and there access.

Space level roles:

Manager : Can manage user access and their roles within the space. Also, can view the instances, service bindings and resources for each application.
Developer : Create, Delete, Manage services and applications within the space. Can associate internal/external URL within an application.
Auditor : Viewer access to all the applications, resources, service bindings, users and user permissions.

Organization and Space properties :

Lite account can only have one organization and one space.
Organizations are logical entities that group spaces can span over multiple regions.
Spaces are linked to a geographical region, and they cannot move between the regions. Also, spaces cannot be transferred between organizations.
Services in space should also reside in the same geographical region and they cannot be moved to other spaces.
Applications from one space cannot talk to the services of other space.
Spaces from different regions can have the same name.
All IAM services can communicate with cloud foundry resources.

Access to Classic Infrastructure

Access to IBM’s classic infrastructure resources(e.g. Creating or deleting virtual server instances) are managed by a different set of permissions. These permissions are categorized into three major sections :

Permissions : Assign user the permissions to create, delete and manage these types of resources : Account, Devices, Network and Services. We can specify individual permissions under each of these resource types, or create permission sets and use those for bulk assignment.
Devices : Assign users with access to devices available in the account to perform any device level operations. The assignment can be for specific devices by selecting individual devices from the list, or can be directly using the device types. The device types can be either Bare metal server, Dedicated host or Virtual server. Checking auto assign functionality will ensure that each time new devices of a specific type are added, the user automatically gets assigned access to those devices.
VPN Subnets : The access to VPN Subnet is required to access the devices that are configured in it. This is assigned using the VPN Subnets tab. You can manually select all the Subnets that the user requires access to work on the devices present in them or can check the auto-assign functionality. This will check the list of devices to which user has been granted access, and then automatically assign the user access to its respective VPN Subnet. You need to be a VPN administrator to perform these actions.

Access to IAM Controlled Resources

IBM Cloud offers an Identity and Access Management service that allows us to grant users with fine grained access to all the resources that are enabled to use the IAM service.

Key terms :

Resource groups : Logical grouping of resources from across regions.
Service ID : Identity for applications, databases and more to authenticate with IBM Cloud similar to how a User ID is an identity for a user.
Access Groups : A group of users and service IDs that is created so that the same access policies can be applied to all the users and service IDs in that group.(E.g., A Database management access group can be created with policies to create, delete and modify databases. All the users/service IDs that part of this group will be able to access and manage the databases).
Policies : Policies are used to define how a user or service id is mapped with a role to access the account resources.
Roles : Roles define what all actions can a user perform on any resource. The access roles are of two types, Platform management role and Service access role.
Platform Management Role : These are the platform level access that are within the account management services context such as, managing user access, creating instances.
Service Access Role : These are service related access and provide access to call the service APIs and manage the service. These permissions are customized depending on the type of service.

Let’s consider the IBM Kubernetes Service and understand the various types of actions within platform management and service access role.

Platform Management Role :

Viewer : Viewer access that will grant the user to list the cluster and its details.
Operator : Can perform platform actions required to configure and operate service instances, such as viewing a service’s dashboard. Can create, reload worker nodes but cannot make any cluster-wide changes or modify credentials.
Editor : Can perform all platform actions except for managing the account and assigning access policies. Users can bind services with resources, configure log forwarding, but cannot modify infrastructure and access policies.
Administrator : Can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. All the actions at platform level including assigning access policies to users/service IDs.

Service Access Role :

Reader : Read only access to service specific resources. Users get read access to most Kubernetes resources in the namespace, but not to certain resources like roles, role bindings, or secrets.
Writer : The user has access to create and edit service specific resources. Users get read and write access to most Kubernetes resources in the namespace, but not to certain resources like roles or role bindings.
Manager : Apart from the writer access, the user has privileged access to create and edit service specific resources. This corresponds to the RBAC cluster admin role in Kubernetes and the user can perform all the actions possible in the Kubernetes space including modifying RBAC policies and adding users.

Understanding the IAM access flow :

User gets invited to the cloud account.
A user without any assigned access has a default resource group(Default) and a default access group(Public access) assigned to it.
Access groups are created and policies are attached to these as per requirement.
The users are added to these access groups to grant them access to the respective services.
All the IAM resources are grouped under resource groups and the users can be directly granted access to these groups.

Key points for IAM :

Lite account can have only a single resource group which is default.
IAM managed resources can be configured with cloud foundry apps regardless of the regions they belong to.
All IAM managed resources are attached to a resource group.
Once provisioned, the resource cannot change its resource group.
Roles can be assigned at Resource Group level or directly to the IAM managed service level.
Roles can be granted to users, service ids or access groups.