IAM access roles

You can use IAM access roles to provide users access to all resources that belong to a resource group. You can also give users access to manage resource groups and create new service instances that are assigned to a resource group.

For step-by-step instructions, see IBM Cloud docs: Assigning access to resources

Access groups

After you set up and organize resource groups in your account, you can streamline access management by using access groups. Create access groups to organize a set of users and service IDs into a single entity. You can then assign a policy to all group members by assigning it to the access group. Thus you can assign a single policy to the access group instead of assigning the same policy multiple times per individual user or service ID.

By using access groups, you can minimally manage the number of assigned policies by giving the same access to all identities in an access group.

For more information see:

• IBM Cloud docs: Setting up access groups.
• Working with IAM access groups

Resource groups

Use resource groups to organize your account's resources into logical groups that help with access control. Rather than assigning access to individual resources, you assign access to the group. Resources are any service that is managed by IAM, such as databases. Whenever you create a service instance from the Cloud catalog, you must assign it to a resource group.

Resource groups work with access group policies to provide a way to manage access to resources by groups of users. By including a user in an access group, and assigning the access group to a resource group, you provide access to the resources contained in the group. Those resources are not available to nonmembers.

The Lite account comes with a single resource group, named "Default", so all resources are placed in the Default resource group. With paid accounts, Administrators can create multiple resource groups to support your business and provide access to resources on an as-needed basis.

For step-by-step instructions, see IBM Cloud docs: Managing resource groups

For tips on configuring resource groups to provide secure access, see IBM Cloud docs: Best practices for organizing resources and assigning access

You can migrate your watsonx.ai Studio, IBM Knowledge Catalog, or watsonx.ai Runtime Service instance from a Cloud Foundry org and space to a resource group in IBM Cloud. See Migrate your service instances from a Cloud Foundry org and space to a resource group.

Service level roles

Service level roles control access to IBM Knowledge Catalog. Predefined or custom roles can be assigned.

See User roles and permissions

Service IDs

You can create service IDs in IBM Cloud to enable an application outside of IBM Cloud access to your IBM Cloud services. Service IDs are not tied to a specific user. If a user leaves an organization and is deleted from the account, the service ID remains intact to ensure that your service continues to work. Access policies that are assigned to each service ID ensure that your application has the appropriate access for authenticating with your IBM Cloud services. See Project collaborators.

One way in which Service IDs and access policies can be used is to manage access to the Cloud Object Storage buckets. See Controlling access to Cloud Object Storage buckets.

For more information, see IBM Cloud docs: Creating and working with service IDs.

Service ID API keys

For extra protection, Service IDs can be combined with unique API keys. The API key that is associated with a Service ID can be set for one-time use or unlimited use. For more information, see IBM Cloud docs: Managing service IDs API keys.

Activity Tracker

The Activity Tracker collects and stores audit records for API calls (events) made to resources that run in the IBM Cloud. You can use Activity Tracker to monitor the activity of your IBM Cloud account to investigate abnormal activity and critical actions, and to comply with regulatory audit requirements. The events that are collected comply with the Cloud Auditing Data Federation (CADF) standard. IBM services that generate Activity Tracker events follow the IBM Cloud security policy.

For a list of events that apply to Cloud Pak for Data as a Service, see Activity Tracker events.

For instructions on configuring Activity Tracker, see IBM Cloud docs: Getting started with IBM Cloud Activity Tracker.

Multifactor authentication

Multifactor authentication (or MFA) adds an extra layer of security by requiring multiple types of authentication methods upon login. After entering a valid username and password, users must also satisfy a second authentication method. For example, a time-sensitive passcode is sent to the user, either through text or email. The correct passcode must be entered to complete the login process.

For more information, see IBM Cloud docs: Types of multifactor authentication.

Single sign-on authentication

Single sign-on (SSO) is an authentication method that enables users to log in to multiple, related applications that use one set of credentials.

Cloud Pak for Data as a Service supports SSO using Security Assertion Markup Language (SAML) federated IDs. SAML federation requires coordination with IBM to configure. SAML connects IBMids with the user credentials that are provided by an identity provider (IdP). For companies that have configured SAML federation with IBM, users can log in to Cloud Pak for Data as a Service with their company credentials. SAML federation is the recommended method for SSO configuration with Cloud Pak for Data as a Service.

The IBMid Enterprise Federation describes the steps that are required to federate your identity provider (IdP). You need an IBM Sponsor, which is an IBM employee that works as the contact person between you and the IBMid team.

For an overview of SAML federation, see IBM Cloud docs: Which SAML federation options exist in IBM Cloud?, which discusses both SAML federation and IBM Cloud App ID. IBM Cloud App ID is supported as a Beta version with Cloud Pak for Data as a Service.

Parent topic: Security