> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # IBM Cloud > Connect an IBM Cloud account with a service ID API key so Oleria can discover IAM users, access groups, access policies, non-human identities, and Activity Tracker activity. 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](#optional-route-activity-to-ibm-cloud-logs) below. Oleria uses this data for dormant account detection, access reviews, and NHI discovery, refreshed on Oleria's [regular sync schedule](/integrations/overview.md#sync-model). ## 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. > [!NOTE] > > 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](https://cloud.ibm.com), 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. > [!NOTE] > > 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: | Service | Role | What Oleria reads with it | | :- | :- | :- | | All Account Management services | **Viewer** platform role | Users, access groups and their members, access policies and roles, service IDs, trusted profiles, account settings, and the account owner. | | IAM Identity Service | **Administrator** platform role, on **All resources** | Every user's and service ID's API keys, the MFA enrollment report, and the inactivity report. | 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: | Row | IAM actions | | :- | :- | | Read users | `user-management.user.retrieve` | | Read groups | `iam-groups.groups.list`, `iam-groups.members.list` | | Read roles | `iam.policy.read`, `iam.role.read`, `iam-access-management.customRole.read` | > [!WARNING] > > **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](#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: | Service | Role | Actions | | :- | :- | :- | | User Management | **Editor** platform role | Disable and enable user accounts, create (invite) users, and delete users. Create and delete need a user API key. | | IAM Access Groups Service | **Editor** platform role | Add or remove a user from a group, and create groups. | | IAM Access Management | **Administrator** platform role | Add or remove a role. | | IAM Identity Service | **Administrator** platform role, already granted for reads | Disable non-human identity. | 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: | Action | IAM actions | | :- | :- | | Disable user account, Enable user account | `user-management.user.retrieve`, `user-management.user.state-change` | | Add a user to a group | `iam-groups.groups.read`, `iam-groups.members.read`, `iam-groups.members.add`, `iam-groups.members.delete` | | Remove a user from a group | `iam-groups.groups.read`, `iam-groups.members.read`, `iam-groups.members.delete`, `iam-groups.members.add`, `iam-groups.members.list` | | Add a role | `iam.policy.read`, `iam.policy.create`, `iam.policy.delete` | | Remove a role | `iam.policy.read`, `iam.policy.update`, `iam.policy.delete`, `iam.policy.create` | | Disable non-human identity | `iam-identity.apikey.get`, `iam-identity.apikey.update`, `iam-identity.serviceid.get`, `iam-identity.apikey.list` | | Delete user | `user-management.user.retrieve`, `user-management.user.delete` | | Create user | `user-management.user.retrieve`, `user-management.user.create`, `user-management.user.delete`. To add the user to access groups, also `iam-groups.groups.read` and `iam-groups.members.add`. | | Create group | `iam-groups.groups.list`, `iam-groups.groups.create`, `iam-groups.groups.read`, `iam-groups.groups.delete`, `iam-groups.members.list`, `iam-groups.rules.list` | 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. > [!WARNING] > > **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: | Field | Notes | | :- | :- | | API key | Required. The API key of the service ID you created. Oleria reads the IBM Cloud account from the key. | | Cloud Logs instance ID | Optional. The GUID of the IBM Cloud Logs instance that receives your account's global Activity Tracker events. Leave it empty to skip activity collection. | | Cloud Logs region | Required when you enter a Cloud Logs instance ID. The region of the Cloud Logs instance, for example `Frankfurt (eu-de)`. | **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](/integrations/overview.md#sync-model) 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. > [!NOTE] > > 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. | Action | What it does | Revert | | :- | :- | :- | | Disable user account | Suspends the user in the account. IBM Cloud keeps the user's access policies and group memberships. | Restores the user's previous state. Skipped if the user is no longer suspended. | | Enable user account | Sets a suspended or VPN-only user back to active. | Restores the user's previous state. Skipped if the user is no longer active. | | Add or remove a user from a group | Adds or removes a user, service ID, or trusted profile as a static member of an access group. If a dynamic rule still adds the identity to the group, Oleria reports it. | Reverses the change. | | Add or remove a role | Adding creates an access policy that grants the role at exactly the role's scope: the whole account, one service, or the IAM service group. For a role that comes from policies limited to a resource group or tags, Oleria copies that exact scope from an existing policy, without its time conditions. If no such policy is left, the action is refused. Removing takes the role out of the identity's own access policies at that scope. It doesn't affect a role the identity gets through an access group or an enterprise policy template - Oleria reports both. | Reverses the change. If someone changed the access policy Oleria created after the grant, Oleria doesn't delete it and the revert fails: review the policy in IBM Cloud and revert it manually. After a removal, a policy that was deleted since isn't re-created. | | Disable non-human identity | Disables a user or service ID API key. For a service ID, disables every active API key it holds. | Re-enables only the API keys the action disabled. | | Delete user | Removes the user from the account. The action's result records the user's state, email, and static access groups. Needs a user API key. | Not supported. IBM Cloud can't restore a removed user, so invite them again instead. | | Create user | Invites a user to the account by email, optionally into access groups. If the email is already in the account, nothing changes. Needs a user API key. | Removes the invited user while the invitation is still pending. Once they accept, revert isn't supported. | | Create group | Creates an access group with the name you provide. If a group with that name already exists, nothing changes. | Deletes the group the action created, but only if it still has its name and no members, rules, or access policies. | 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. > [!NOTE] > > 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](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.