IBM Cloud Docs
Managing authorizations to grant access between services

Managing authorizations to grant access between services

Use IBM Cloud® Identity and Access Management (IAM) to create or remove an authorization that grants IBM Cloud Activity Tracker Event Routing access to work with other services.

Authorizations

Many of the capabilities of IAM are focused on managing and enforcing user and application access to IBM Cloud resources. However, you might encounter other scenarios in which you need to provide one service with access to a user's resource in another service. This type of access is called an authorization.

In a service to service (S2S) authorization:

  • The source service is the service that is granted access to the target service.
  • The roles that you select define the level of access for the source service.
  • The target service is the service that you are granting permission to be accessed by the source service based on the roles that you assign.
  • A source service can be in the same account where the authorization is created or in another account.
  • The target service is always in the account where the authorization is created.

You can view whether the source service is located in the current account or another account by viewing the Source account column for the specific authorization on the Authorizations page in the IBM Cloud® console.

For more information, see Using authorizations to grant access between services.

Service to service authorizations

The following table lists the different S2S authorizations that you can configure when you use the IBM Cloud Activity Tracker Event Routing service:

S2S authorizations.
S2S Authorization Source service Target service
Authorize access to write data into a bucket IBM Cloud Activity Tracker Event Routing IBM Cloud Object Storage
Authorize access to send data to the IBM® Event Streams for IBM Cloud® service IBM Cloud Activity Tracker Event Routing IBM® Event Streams for IBM Cloud®
Authorize access to send data to the IBM Cloud Logs service IBM Cloud Activity Tracker Event Routing IBM Cloud Logs

Service to service authorizations are supported in the following use cases:

  • IBM Cloud Activity Tracker Event Routing and the target service are in the same account.
  • IBM Cloud Activity Tracker Event Routing and the target service are in different accounts.

Permissions to manage authorizations

You must have access to the target service to manage authorization between services.

If you create an authorization between a service in another account and a target service in your current account, you need to have access only to the target resource. For the source account, you need only the account ID.

The autorization that you define for the IBM Cloud Activity Tracker Event Routing service requires that the ID that you use to create the S2S authorization has the following platform roles:

Actions on the target service that are required to manage authorizations
Action Administrator Operator Editor Viewer
View all authorizations that are configured in the account Checkmark icon
Create authorizations Checkmark icon
Delete authorizations Checkmark icon

Users can only see authorizations that they configure in the account.

The autorization that you define for the IBM Cloud Activity Tracker Event Routing service requires that the ID that you use to create the S2S authorization has the following service role per type of authorization:

S2S authorizations.
S2S Authorization Service Service role
Authorize access to write data into a bucket IBM Cloud Object Storage Object Writer
Authorize access to the IBM® Event Streams for IBM Cloud® service IBM® Event Streams for IBM Cloud® Writer
Authorize access to send data to the IBM Cloud Logs service IBM® Cloud Logs Sender

Creating an authorization

Choose one of the following options to create a S2S authorization:

Removing an authorization

Choose one of the following options to remove a S2S authorization:

If the source service is removed from the account, any policies that are created by that service for its dependent services are deleted automatically. Similarly, if the dependent service is removed from the account, any access policies that are delegated to that service are also deleted.