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-write access. The script creates the IAM group, the API-only service user, group membership, and the two policies Uniskai reads. With read-write access, Uniskai can both observe your cost and inventory and take optimization actions (for example, stop or resize resources).
The whole flow is: copy the command from the Uniskai UI → run it in OCI Cloud Shell → check the output → create the API signing key → hand the values to Uniskai.
Note: For read-only access instead, use the Automatic Setup (Read-Only) 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-write here grants read on every family plus use on the resource types Uniskai operates on, while read-only grants read only.
Note: Prefer clicking through the Console by hand? See the Manual Setup (Read/Write) 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 creates and configures two IAM policies for the group:
CUR policy — cross-tenancy read access to Oracle's Cost & Usage Reports.
Platform policy — in-tenancy read access to the managed resource families plus Use the same permission terminology throughout the guide (either consistently use use or explain why manage is required).
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 manage 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-write access. Uniskai then shows the matching command block.
Setup steps
Step 1 — Copy the command from the Uniskai UI
In the Uniskai UI, on the Oracle (OCI) connection screen, copy the command block shown for Read-write access. Click the copy icon rather than typing it by hand — the download link is version-pinned and kept current in the 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 — OCI displays the generated private key only once
In the Console, go to Identity & Security → Domains → Default domain → Users and open 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
.pemsomewhere 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
Provide the following 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-write (manage) access to the managed resource families, plus read access to the cost and usage reports.
Once you submit the configuration file and private key, 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.
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.
manage includes read. Read-write access also covers everything read-only access does.
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 handed over the matching User OCID, fingerprint, and private key.