> ## 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. # Oracle Cloud > Connect Oracle Cloud Infrastructure (OCI) with an API signing key so Oleria can discover identity-domain users and groups, IAM policies and admin roles, non-human identities, and audit activity. Connect Oracle Cloud Infrastructure (OCI) to Oleria to see who and what can act in your tenancy: identity-domain users and groups, IAM policies and the groups they grant, identity-domain administrator roles, non-human identities (service users, OAuth applications, dynamic groups, and per-user API keys and tokens), and what changed - from the OCI Audit service. A single Oleria connection covers **one OCI tenancy** - Oleria reads every active identity domain in it that you give it access to (see [Assign identity-domain administrator roles](#set-up-the-integration)), and audit events from every subscribed region. ## What Oleria discovers | Area | Detail | | :- | :- | | **Users** | Every user in every active identity domain, with MFA status, last successful login, and last password change. Federated users are marked as signing in through SSO, and users of the OCI `External` user type as external. | | **Groups** | Identity-domain groups with their members and owners, including dynamic-membership groups with their membership rule. | | **Roles** | IAM policies (each statement is kept on the role, and the groups and dynamic groups it names are linked to it) and identity-domain administrator roles (Identity Domain Administrator, Security Administrator, Application Administrator, User Administrator, User Manager, Help Desk Administrator, Audit Administrator) with their user and group grants. A user is marked as an administrator when an unconditional `manage all-resources in tenancy` statement applies to them (through a group, or to `any-user` / `any-group`), or when they are in the Default domain's **Administrators** group, or hold Identity Domain Administrator or Security Administrator. Dynamic groups named in such a statement are marked as administrators too. | | **Non-human identities** | Service users, OAuth client applications, and dynamic resource groups (workload identities), each with the user who created it as owner. Identity propagation trusts that allow impersonation show which OAuth applications can impersonate which service users. Each user's API signing keys, auth tokens, customer secret keys, OAuth 2.0 client credentials, SMTP credentials, and database credentials are discovered as credentials of that user. | | **Risk** | Users that the identity domain's adaptive security rates as high risk, with each risk provider's score. Requires adaptive security to be enabled in the domain. | | **Activity** | Management events from OCI Audit across every subscribed region and compartment, up to the 365-day audit retention - sign-ins, user, group, policy, and credential changes, and other API calls. Oleria's own read calls are excluded. | ## Prerequisites * An OCI tenancy, and an administrator of it: a member of the Default domain's **Administrators** group (tenancy administrator), who can create a user, a group, and a root-compartment policy, and assign identity-domain administrator roles. * Your tenancy's **OCID** and **home region** (OCI Console -> **Profile** -> **Tenancy**). * An RSA key pair in PEM format for the API signing key (OCI can generate one for you). ## Set up the integration **1. Create a user and group for Oleria** In the OCI Console, go to **Identity & Security** -> **Domains** -> your **Default** domain. Create a group (for example, `oleria-connector`), then create a user (for example, `oleria-connector`) and add it to the group. A dedicated user keeps Oleria's access separate from any person's. **2. Grant IAM policy permissions** Go to **Identity & Security** -> **Policies**, select the **root compartment**, and create a policy with these statements (replace the group name if you chose another): ```text theme={null} Allow group 'Default'/'oleria-connector' to inspect tenancies in tenancy Allow group 'Default'/'oleria-connector' to inspect compartments in tenancy Allow group 'Default'/'oleria-connector' to inspect domains in tenancy Allow group 'Default'/'oleria-connector' to inspect policies in tenancy Allow group 'Default'/'oleria-connector' to read audit-events in tenancy ``` **3. Assign identity-domain administrator roles** In the identity domain that holds the Oleria user (the **Default** domain, if you followed the first step), open **Admin roles** and assign the Oleria user: | Role | Used for | | :- | :- | | **Audit Administrator** | Reading users and groups | | **Application Administrator** | Reading OAuth applications, administrator roles, and grants; deactivating OAuth applications (Disable NHI) | | **User Administrator** | Reading users' credentials and dynamic groups; adding and removing group members; creating and deleting users and creating groups | | **Security Administrator** (optional) | Reading identity propagation trusts (impersonation) | | **User Manager** (actions) | Disabling and enabling users; deactivating service users (Disable NHI) | | **Identity Domain Administrator** (actions) | Granting and removing administrator roles. Covers every action on its own. | Disable NHI shows as available only when Oleria has both User Manager and Application Administrator (or Identity Domain Administrator), since it covers both service users and OAuth applications. Administrator roles can only be granted inside their own identity domain. For every **other** identity domain you want Oleria to read, add a policy statement for the Oleria group instead: ```text theme={null} Allow group 'Default'/'oleria-connector' to manage domains in tenancy where target.domain.name = '' ``` > [!NOTE] > > `manage domains` makes the group an administrator of that domain, which also covers the remediation actions there. Data in a domain Oleria can't read is skipped, and the integration's Capabilities tab shows the permissions it checks. If no domain grants a read, or OCI refuses a read partway through, the sync fails with the missing permission instead of showing incomplete data. For a read-only connection, omit the action roles - discovery still works, and the remediation actions show as needing permission. **4. Add an API signing key** Open the Oleria user's details page, go to **API keys** -> **Add API key**, and either generate a key pair (download the private key) or paste your own public key. Copy the **fingerprint** OCI shows for the key. ## Connect Oracle Cloud to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **Oracle Cloud**. **2. Complete the connection form** | Field | Notes | | :- | :- | | **Tenancy OCID** | Required. It can't be changed after the connection is created. | | **User OCID** | Required. The OCID of the Oleria user the API key belongs to. | | **Key fingerprint** | Required. The fingerprint OCI shows for the API key (`aa:bb:cc:...`). | | **Private key** | Required. The PEM private key, including the `BEGIN` and `END` lines. Stored in a secret vault - only a reference is kept on the connection. When you edit the connection, leave it blank to keep the stored key. Enter a new key whenever you change the User OCID or Key fingerprint, for example when you rotate the API key. | | **Private key passphrase** | Only if the private key is encrypted. Enter it together with the private key. | | **Home region** | Required. Your tenancy's home region identifier, for example `us-ashburn-1`. | **3. Complete the connection** Select **Authenticate**. Oleria checks that the private key matches the fingerprint, authenticates to OCI, verifies the tenancy matches the Tenancy OCID you entered and that the region is the tenancy's home region, checks that it can read users, audit events, and API keys, and begins the first sync. ## Verify the integration Confirm Oracle Cloud appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered users, groups, roles, non-human identities, risks, and activity in your Oleria workspace. ## Remediation actions | Action | What it does | | :- | :- | | **Disable user** / **Enable user** | Deactivates or reactivates the identity-domain user. Revert restores the prior status, unless it was changed again since. | | **Add user to group** / **Remove user from group** | Changes the group's membership. The user and the group must be in the same identity domain. Revert applies the inverse change. | | **Add user to role** / **Remove user from role** | Grants or removes an identity-domain administrator role directly on the user. A role the user holds only through a group is refused - remove the group's grant instead. Revert applies the inverse change. IAM policies can't be assigned to a user - change the policy or the user's groups instead. | | **Disable NHI** | Deactivates a service user or a user-created OAuth application. Revert reactivates it if it is still inactive. | | **Create user** / **Create group** | Creates a user or group in the identity domain of Oleria's connection user (or the Default domain). A new user is created inactive unless you choose to activate it, and sets their own password through OCI's account activation, so password options are ignored. Groups can't be assigned while creating a user - use **Add user to group** afterwards. If a user with the same user name and primary email already exists, the action succeeds without changing it. Any other existing user name, and any existing group name, is refused and nothing is created. Revert deletes only what the action created. A group is deleted only while it has no members or administrator-role grants and no IAM policy names it. If Oleria can't read every IAM policy, the group is kept. | | **Delete user** | Deletes the identity-domain user. This can't be reverted; use **Disable user** when the account may be needed again. | Every action reads the current state first (if nothing needs to change, nothing is recorded). Creates, deletes, and status and membership changes are confirmed by reading them back; role changes are confirmed by OCI's response to the grant or removal. If a user or group isn't found and an identity domain Oleria can't read might hold it, the action fails with a permission error. > [!NOTE] > > Oleria refuses to disable or delete its own connection user, remove it from groups, or remove its roles, refuses to delete service users (use **Disable NHI**), and refuses to deactivate OAuth applications provisioned by Oracle. Dynamic groups, API signing keys, auth tokens, and other credentials have no disabled state OCI can report back, so Disable NHI isn't offered for them - delete them in the OCI Console instead. ## Known limitations * **Commercial realm (oc1) only.** Government and sovereign realms use different endpoints. * **Policy `where` conditions are not evaluated.** A conditional statement is kept on its role, but never makes its subjects administrators. The one exception is the `manage domains ... where target.domain.name = ''` statement from the setup, which Oleria counts as administrator rights in that domain for remediation actions. * **Unreadable policies.** If Oleria can't read IAM policies, roles show only identity-domain administrator roles, and administrators come only from those roles and the Default domain's Administrators group. * **Cloud resources are not discovered.** Compartments are used to scope audit reads, not modeled as resources. * **Not yet modeled:** sign-on and MFA policies, identity providers and federation settings, application assignments (SAML and catalog apps), cross-tenancy `Endorse` / `Admit` statements, and network sources. * **No session revocation.** OCI has no API to sign a user out of their identity-domain sessions, so Oleria can't revoke sessions. Disable the user instead. * **Not yet validated against a live tenancy.** This integration was built from Oracle's API documentation. Contact support if a sync reports a permission or format error. * **Identity-domain rate limits** depend on the domain type; Oleria paces its reads to stay within each domain type's limit, so large Free domains sync more slowly. ## 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.