Oracle Cloud

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), 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

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.

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):

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

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:

Allow group 'Default'/'oleria-connector' to manage domains in tenancy where target.domain.name = '<domain name>'

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.

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

Open the integration

Go to your Oleria workspace, select Integrations -> select Oracle Cloud.

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`.

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.

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 = '<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.

Overview

Generic connectors

Identity providers

HR systems

Cloud infrastructure

Applications

Ticketing

Messaging

What Oleria discovers

Prerequisites

Set up the integration

Connect Oracle Cloud to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us

​What Oleria discovers

​Prerequisites

​Set up the integration

​Connect Oracle Cloud to Oleria

​Verify the integration

​Remediation actions

​Known limitations

​Contact us

What Oleria discovers

Prerequisites

Set up the integration

Connect Oracle Cloud to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us