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 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:
Action | Administrator | Operator | Editor | Viewer |
---|---|---|---|---|
View all authorizations that are configured in the account | ||||
Create authorizations | ||||
Delete authorizations |
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 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:
- Remove a S2S authorization through the UI
- Remove a S2S authorization by using the CLI
- Remove a S2S authorization by using the API
- Remove a S2S authorization by using terraform
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.