Skip to main content
Connect IBM Cloud to Oleria to see who and what can act on your IBM Cloud account through Identity and Access Management (IAM), and what they do with that access. Each connection covers one IBM Cloud account.

​
What Oleria discovers

  • Users in the account, with their state, MFA requirement and enrolled MFA factor, SSO state, whether they hold an active API key, and their last authentication from the IAM inactivity report.
  • The account owner, flagged as an admin and shown with an Account owner role, because IBM Cloud gives the owner full access outside of access policies.
  • Access groups and their members, both static members and members added by dynamic rules. The Public Access group appears with a single anonymous member, because any access it grants is open to anyone.
  • Access policies as roles. Each role is an IAM role on a service, such as Editor on IAM Identity Service, with the users, service IDs, trusted profiles, and access groups each policy grants it to. Resource and time-based conditions that narrow a policy are kept with the grant. Principals with an account-wide Administrator platform role, directly or through an access group, are flagged as admins. That’s Administrator on all resources, on All Account Management services, or on IAM Identity Service, IAM Access Groups Service, IAM Access Management, or User Management, with no resource conditions.
  • Non-human identities:
    • Service IDs, and who created each one.
    • Trusted profiles, and which users and service IDs, including service IDs in other accounts, can apply each one. Claim rules and compute resource links appear in the profile’s details.
    • User API keys, and the user that owns each one.
    • Service ID API keys, the service ID that owns each one, and who created it.
  • Activity from Activity Tracker IAM and user management events in your IBM Cloud Logs instance, for up to 30 days of history. Oleria leaves out its own reads and sign-ins. Activity is optional and needs the Cloud Logs setup below.
Oleria uses this data for dormant account detection, access reviews, and NHI discovery, refreshed on Oleria’s regular sync schedule.

​
Prerequisites

  • An IBM Cloud account, and permission to create service IDs and assign access in Manage -> Access (IAM).
  • To collect activity, an IBM Cloud Logs instance, and permission to configure Activity Tracker Event Routing.
  • Admin access on the Oleria platform to add a new integration.
Use a service ID API key for Oleria. A user API key also works, but it carries that user’s access in every IBM Cloud account they belong to, and it stops working if the user leaves.IBM Cloud doesn’t let a service ID invite users to the account or remove them from it. To use the Create user and Delete user actions, connect with a user API key that holds the roles below. Every other action works with a service ID API key.

​
Create a service ID and API key for Oleria

1

Create the service ID

In the IBM Cloud console, go to Manage -> Access (IAM) -> Service IDs and select Create. Enter a name such as oleria-connector.
2

Create the API key

Open the service ID, go to the API keys tab, and select Create. Copy the API key - you’ll paste it into Oleria in the next section.
IBM Cloud shows the API key only once, when you create it. Copy it now and store it securely.
3

Grant read access

On the service ID’s Access tab, select Assign access, or add the service ID to an access group that holds these policies:Oleria needs Administrator on IAM Identity Service, on all resources: IBM Cloud returns every user’s API keys and the MFA enrollment report only to that role. Don’t limit the policy to specific service IDs or resource types. Without account-wide access, Oleria can’t sync users or non-human identities.These are the IAM actions behind the Read users, Read groups, and Read roles rows on the integration’s Capabilities tab:
Administrator on IAM Identity Service lets the API key manage the API keys of every user and service ID in the account. Treat the API key as an admin credential.
4

(Optional) Grant permissions for remediation actions

To let Oleria run remediation actions, also assign the service ID these roles on All resources. Oleria doesn’t count a policy limited to specific resources. They’re required for actions only:Before it shows an action as available, Oleria reads the service ID’s access policies, direct and through its access groups, and checks them for these IAM actions:Every action also needs iam.policy.read and iam-groups.groups.list, so Oleria can read its own access policies. The Viewer role on All Account Management services covers both. Until the service ID holds these roles, Oleria shows the actions as missing permissions.
Administrator on IAM Access Management lets the API key grant any role in the account, including to itself. Treat an API key with remediation permissions as an admin credential.

​
(Optional) Route activity to IBM Cloud Logs

IAM and user management events are global events in IBM Cloud. Oleria reads them from an IBM Cloud Logs instance that Activity Tracker Event Routing sends them to. Skip this section if you don’t need activity.
1

Choose a Cloud Logs instance

Create an IBM Cloud Logs instance, or choose an existing one. Note its region, and copy its instance ID (a GUID) from the instance’s details in your Resource list.
2

Route global events to the instance

In Activity Tracker Event Routing, create a target for the Cloud Logs instance. Then create a route with a rule whose locations include global, and send it to that target.Activity Tracker Event Routing needs a service-to-service authorization with the Sender role on the Cloud Logs instance. If it isn’t created when you add the target, create it in Manage -> Access (IAM) -> Authorizations, from Activity Tracker Event Routing to the Cloud Logs instance.Oleria queries the Priority insights tier. If you use TCO policies in Cloud Logs, keep these events in Priority insights. Oleria reads up to 30 days of history, limited by your Priority insights retention period.
3

Grant the service ID access to the instance

Assign the service ID the Reader service role on the Cloud Logs instance. Oleria uses logs.logs-data-api-high.read to query events.

​
Connect IBM Cloud to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the IBM Cloud tile.
2

Complete the connection form

Fill in the connection form:
3

Save the integration

Select Authenticate to validate the API key and save the integration.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. Oleria syncs users, access groups, access policies, non-human identities, and activity on its regular sync schedule once the initial sync completes. Each sync asks IBM Cloud for a new inactivity report and reads it on the next sync, so last authentication dates appear from the second sync onward.
If you rotate the API key, edit the integration in Oleria and enter the new API key. To change only the Cloud Logs settings, you can leave API key empty and Oleria keeps the stored key. Clear Cloud Logs instance ID to stop collecting activity. The new API key must belong to the same IBM Cloud account. To connect a different account, add a new integration.

​
Remediation actions

Oleria can take these actions in IBM Cloud when the connection has the roles listed above. Every action except Delete user can be reverted. Oleria never undoes someone else’s change: if the target changed after the action ran, Oleria skips the revert or asks you to revert manually, and the revert result says which. Oleria never suspends or deletes the account owner or the user it connects with. It also refuses to remove the identity it connects with from a group or role, to disable its own service ID or any API key of the identity it connects with, and to disable API keys or service IDs that belong to another account. The Public Access group and the Account owner role can’t be changed.
Trusted profiles have no disabled state in IBM Cloud, so Oleria can’t disable them. To stop a trusted profile from being used, remove its trusted identities, claim rules, or compute resource links in the IBM Cloud console.

​
Known limitations

  • Last password change isn’t collected. IBMid, not the IBM Cloud account, manages passwords, and no IBM Cloud account API returns the date.
  • SSO state is account-level. IBM Cloud reports whether the account has an active identity provider, not whether each user signs in through it, so every user shows the same SSO state.
  • Failed sign-ins don’t appear in activity. IBM Cloud IAM doesn’t generate events for failed logins.
  • Activity needs an IBM Cloud Logs instance and an Activity Tracker Event Routing route for the global location. Without them, Oleria collects no activity.
  • Missing Cloud Logs access shows as a sync error on the integration, not on the Capabilities tab. Grant the service ID the Reader role on the Cloud Logs instance, and Oleria reads the missed activity on the next sync.
  • One account per connection. Child accounts of an IBM Cloud enterprise aren’t collected. Connect each account separately.
  • Cloud resources, authorization policies between services, and classic infrastructure permissions aren’t collected.

​
Contact us

For questions about this integration, contact us at support@oleria.com.