How IBM Cloud IAM works
Learn about what IBM Cloud Identity and Access Management (IAM) is, how IAM works, what features are available, and how to access the console, CLI, and APIs to work with IAM in your account.
IAM enables you to securely authenticate users for platform services and control access to resources consistently across IBM Cloud. A set of IBM Cloud services is enabled to use IBM Cloud IAM for access control, and are organized into resource groups within your account so you can give users access quickly to more than one resource at a time. Each of these services is labeled as "IAM-enabled" in the catalog. You can use IAM access policies to assign users, service IDs, and trusted profiles access to resources within your account. And, you can group users, service IDs, and trusted profiles into an access group to easily give all members of the group the same level of access.
You can use trusted profiles to automate the grouping and granting of access to users, services, and app identities. By specifying conditions based on SAML attributes for users whose identity is federated from your external identity provider (IdP), users can be granted access to resources without having to be invited to the account if they meet those conditions. For service and app identities, you can define fine-grained authorization for all applications that are running in a compute resource without creating service IDs or managing the API key lifecycle for applications.
For classic infrastructure that doesn't support the use of IBM Cloud IAM policies for managing access, you can use the classic infrastructure permissions documentation.
What features are provided?
IBM Cloud IAM provides a wide range of features for your identity and access management needs.
User management
With unified user management, you can add and delete users in an account for both platform and classic infrastructure services. You can organize a group of users in an access group to make assigning access for more than one user or service ID at a time a quick and easy task.
Fine-grained access control
Access for users, service IDs, access groups, and trusted profiles are defined by a policy. Within the policy, the scope of access can be assigned to a set of resources in a resource group, a single resource, or account management services. After the target is set, you can define what actions are allowed by the subject of the policy by selecting access roles. Roles provide a way to tailor the level of access that is granted for the subject of the policy to perform actions on the target of policy, whether it is platform management tasks within the account or accessing a service's UI or completing API calls.
You can also add time-based conditions to a policy that defines when the policy grants access, whether you want to grant temporary access to resources in your account or allow access during recurring time windows. For more information, see Limiting access with time-based conditions.
Access groups for streamlined access management
Quickly and easily assign access for a group of users, service IDs, or trusted profiles that are organized in an access group by assigning access to the group, and then add or remove identities as needed to grant or deny access to account resources. Access groups enable you to manage a minimal number of policies in the account. For more information, see Setting up access groups.
Trusted profiles for eliminating the need to manage credentials
Automatically grant federated users access to your account with conditions based on SAML attributes from your corporate directory. Trusted profiles can also be used to set up fine-grained authorization for applications that are running in compute resources. This way, you aren't required to create service IDs or API keys for the compute resources. Assign access to the profile by adding it to an access group or by assigning individual policies, and then add or remove conditions as needed to grant or deny access to account resources. By using trusted profiles, you can centrally manage the access lifecycle to multiple IBM Cloud assets. For more information, see Creating trusted profiles.
Federated users
Your users might already have identities outside of IBM Cloud in your corporate directory. If your users need to work with IBM Cloud resources or work with applications that access those resources, then those users also need IBM Cloud credentials. You can use a trusted profile to specify permissions for users whose identity is federated from your organization or an external IdP. By using your IdP, you can provide a way for users in your company to use single sign-on (SSO). To connect your federated users with IBM Cloud resources, see Federating users to IBM Cloud.
Video transcript
We are excited to introduce the latest and greatest identity type: IBM Cloud trusted profiles. You expect the most reliable and efficient way to manage access to your account, so let’s learn about how you can use trusted profiles.
Previously, organizing identities and assigning access was limited to access groups, where each user is added to the account manually.
As an account owner, you can save time and automatically grant federated users access to your accounts by leveraging the attributes that already exist in your corporate directory.
Simply add conditions based on SAML attributes to define which federated users can apply a profile. This way, changes in your directory immediately affect access to resources.
As a federated user, you might have the option to apply one of many trusted profiles. After you log in, you can apply a profile, or continue to the console.
Imagine a scenario where you want to complete developer-related tasks, like working with the service instances from your application components. You can select the Developer profile when logging in to ensure that you have the access you need.
Similarly, if you want to complete an administrator-related task, you can select the Admin profile that has privileged permissions. This way, you reduce the risk of taking privileged actions by mistake.
You also have the option to log in to the account without applying a profile by continuing to the console.
To learn more about how trusted profiles work check out our IBM Cloud Identity and Access Management documentation which includes tutorials and other helpful resources to get started!
Compute resources
By using trusted profiles, you can define fine-grained authorization for all applications that are running in a compute resource without creating service IDs or managing the API key lifecycle for applications. The trusted profiles provide better control for granting access to compute resources.
- Application developers can programmatically retrieve a token that is associated with the compute resource identity that they are running on. That token is used to get the trusted profile identity token, which is used to access services and resources on IBM Cloud.
- Applications running on a compute resource can have a flexible, but secure way to access other IBM Cloud services from within compute resources. For example, it's more secure not having to store API keys.
- All compute resource instances that share certain conditions such as name, namespace, tags, or location, their identities are mapped to a common profile and can share access to IBM Cloud resources. This common identity makes it possible to give the applications within various compute resources access to an external resource one time rather than cluster-by-cluster.
Enterprise-managed IAM templates for centrally managing access in enterprises
Your enterprise can easily scale access management and ensure consistent account security settings throughout the organizaiton by using enterprise-managed IAM templates. You can create templates for IAM resources like access groups, trusted profiles, and account security settings that you assign throughout the enterprise. When you assign an IAM template to child accounts, enterprise-managed IAM resources are created in the child accounts that you select.
For example, there might be a certain job role in every child account that requires the same permissions. You can create an access group template with the necessary access polices and assign the template to all of the child accounts in your enterprise. This way, you reduce policy drift and can be certain that users with that job role have only the access that is necessary in each account.
For more information, see How enterprise-managed IAM works.
API keys for user authentication
You can create multiple API keys for a user to support key rotation scenarios, and the same key can be used for accessing multiple services. IBM Cloud API keys enable users who use two-factor authentication or a federated ID to automate authentication to the console from the command line. A user can also have a single classic infrastructure API key that can be used to access classic infrastructure APIs; however, this is not required as you can use IBM Cloud API keys to access the same APIs. For more information, see Understanding API keys.
Service IDs
A service ID identifies a service or application similar to how a user ID identifies a user. These are IDs that can be used by applications to authenticate with an IBM Cloud service. Policies can be assigned to each service ID to control the level of access that is allowed by an application that uses the service ID, and an API key can be created to enable the authentication. For more information, see Creating and working with service IDs.
Infrastructure-as-a-Service (IaaS) doesn't support operations that are made by service IDs. If an account includes IaaS and PaaS, administrative functions that are made by a service ID might not work as intended if the operation depends on API calls to IaaS. In an account that includes IaaS, be sure that account administrators complete the administrative functions. For example, functional IDs can be used for administrative functions. In some cases, IBM support might be able to assist with some administrative functions that span both IaaS and PaaS.
Multifactor authentication
You can require multifactor authentication (MFA) for every user in the account or just users with non-federated IDs who do not use SSO. All users with an IBMid use a time-based one-time passcode (TOTP) MFA factor, and any users with a different type of ID must be enabled to use the TOTP, security questions, or external authentication factor separately. For more information, see Types of multifactor authentication.
How do I use IBM Cloud IAM?
You can access and use IBM Cloud IAM through the Access (IAM) UI, CLI, or API.
- To access IBM Cloud IAM by using the console, go to Manage > Access (IAM).
- Go to Managing IAM access, API keys, service IDs, and access groups to review the available CLI commands.
- Go to the following API docs to review the available APIs: