Overview
This guide explains how to connect your Oracle Cloud Infrastructure (OCI) account to Uniskai automatically by running a setup script that provisions all required OCI IAM resources automatically granting read-only access. The script creates the IAM group, the API-only service user, group membership, and the two policies Uniskai reads. With read-only access, Uniskai observes your cost and inventory but does not take any actions on your resources.
The whole flow is: start the connection in Uniskai and copy the command → run it in OCI Cloud Shell → check the output → create the API signing key → return to Uniskai and enter the values.
Note: For read-write access instead, use the Automatic Setup (Read/Write) guide. Both run the same kind of script and create the same group, user, and Cost & Usage Reports policy; they differ only in the access level on the resource grants — read-only here grants read on every resource family, while read-write additionally grants use on the resource types Uniskai operates on.
Note: Prefer clicking through the Console by hand? See the Manual Setup (Read-Only) guide.
How it works
Uniskai connects to your tenancy as a dedicated service user that belongs to a group. The setup script provisions all of this for you and creates and configures two IAM policies:
CUR policy — cross-tenancy read access to Oracle's Cost & Usage Reports.
Platform policy — in-tenancy read access to the managed resource families, plus IAM inspect grants that let Uniskai verify the permissions were applied.
The objects created by the script:
Resource | Name | Purpose |
Group | uniskai-group | Holds the service user; all permissions are granted to this group. |
User | uniskai-service-user | API-only service identity Uniskai authenticates as. |
Membership | user → group | Makes the user inherit the group's grants. |
Policy | uniskai-cur-policy | Cross-tenancy read access to Oracle's Cost & Usage Reports. |
Policy | uniskai-policy | In-tenancy read access + IAM |
The script does not create the API signing key — OCI reveals a private key only once, so you generate and download it yourself (Step 4).
Prerequisites
Before you start:
Sign in to the OCI Console as a tenancy administrator (or a user able to manage groups, users, and root-compartment policies).
In the Uniskai UI, start adding an Oracle (OCI) account and choose Automatic setup with Read-only access. Uniskai then shows the matching command block.
Setup steps
Step 1 — Start adding the Oracle account in Uniskai
In Uniskai, open Account Manager.
Start adding a new account and choose Oracle (OCI).
Enter a name for the Oracle account.
Select Read-only access and choose Automatic setup.
Uniskai displays a command block for the selected access. Click the copy icon to copy it — always copy from the UI, the download link is version-pinned and kept current there.
Keep this Uniskai screen open — you will return to it in Step 5 to enter the values the script produces.
Note: The exact URL is version-pinned and may change. Always copy the current command from the Uniskai UI.
Step 2 — Run it in OCI Cloud Shell
OCI Cloud Shell already has everything the script needs (the OCI CLI and jq installed, authenticated as you, with OCI_TENANCY and OCI_REGION preset), so there is nothing to configure.
Open Cloud Shell — the >_ icon in the top-right toolbar of the Console.
Paste the command block you copied in Step 1 and press Enter.
The command block downloads the script, makes it executable, and runs it
Step 3 — Check the output
The script prints each permission it grants, then a summary. On success you will see:
Setup complete. Collect these values for Uniskai:
Tenancy OCID : ocid1.tenancy.oc1..xxxx
User OCID : ocid1.user.oc1..xxxx
Region : us-ashburn-1
Note: If the script stops early, it tells you why (for example, it must run where OCI_TENANCY and OCI_REGION are set — which is automatic in Cloud Shell). Re-running is safe: the group, user, and membership are reused, and the policies are reconciled to the correct statements, so re-running also repairs a tenancy onboarded with an older script.
Step 4 — Create the API signing key
The script intentionally does not create the API key — O"OCI displays the generated private key only once, so you generate and download it yourself.
In the Console, go to Identity & Security → Domains → Default domain → User management, open the Users section, and click uniskai-service-user (its OCID was printed in Step 3).
In the left panel under Resources, click API keys (may appear under Tokens and keys).
Click Add API key.
Choose Generate API key pair.
Click Download private key and save the .pem somewhere safe — this is the only time OCI shows it. (You may download the public key too; it is optional.)
Click Add.
A Configuration file preview dialog appears. It contains the user OCID, fingerprint, tenancy OCID, and region. Click Copy to copy the whole configuration file — you will provide it to Uniskai in Step 5.
(Optionally confirm the user, tenancy, and region match what the script printed in Step 3.)
Step 5 — Hand these to Uniskai
Go back to the Uniskai Oracle connection screen you opened in Step 1. You don't need to collect each value separately — the configuration file you copied in Step 4 already contains them. Provide to Uniskai:
The configuration file copied in Step 4 (it includes the user OCID, fingerprint, tenancy OCID, and region).
The private key (.pem) downloaded in Step 4.
Uniskai reads the values from the configuration file and runs the credentials check.
Running outside Cloud Shell (advanced)
If you cannot use Cloud Shell, run the script on any host with the OCI CLI configured against the target tenancy:
Install the OCI CLI and jq, then configure the CLI as a tenancy admin: oci setup config.
Export the two variables Cloud Shell would otherwise preset:
bash
export OCI_TENANCY="ocid1.tenancy.oc1..xxxx" # your tenancy OCID
export OCI_REGION="us-ashburn-1" # your home region
3. Run the same curl / chmod / ./… block from Step 1.
Results
After completing the steps:
uniskai-group, uniskai-service-user, the group membership, and the two policies (uniskai-cur-policy, uniskai-policy) exist in your tenancy.
Uniskai authenticates as the service user and has read-only access to the managed resource families and the cost and usage reports — it observes, but does not change, your resources.
Once you submit the configuration file and private key in Step 5, Uniskai runs a credentials check during onboarding to confirm the grant.
Key notes / limitations
Always copy the command from the Uniskai UI. The download link is version-pinned and kept current there — do not type it by hand or reuse an old URL.
The script does not create the API key. Generate and download it yourself in Step 4; the private key is shown only once.
Re-running is safe. The group, user, and membership are reused and the policies are reconciled, so re-running also repairs a tenancy onboarded with an older script.
Read-only takes no actions. Uniskai can observe cost and inventory but cannot stop, resize, or otherwise change your resources.
Verifying it worked
Uniskai runs a credentials check during onboarding to confirm the grant. If it reports missing permissions, re-run the command (it reconciles the policies) and make sure you submitted the matching User OCID, fingerprint, and private key.