Oracle Cloud Setup Guide

Connect an Oracle Cloud tenancy to CloudSavvy

CloudSavvy only ever reads from your tenancy. It creates nothing, changes nothing and deletes nothing — every permission below is a read. Oracle never sees your CloudSavvy account, and CloudSavvy never sees your Oracle password.

Step 1 — Create an API signing key

CloudSavvy signs its requests with an API key rather than logging in as you. You create a key pair, upload the public half to OCI, and give CloudSavvy the private half.

The simplest route is to let Oracle generate the key, because it gives you the private key and the matching fingerprint together:

In the OCI Console, open the Profile menu and choose User settings.
Under Resources, select API keys, then Add API key.
Choose Generate API key pair and click Download private key.
Click Add. Oracle then shows the fingerprint — copy it.

If you would rather generate the key yourself, create it locally and upload only the public half, then choose Paste a public key in the Console:

# Generate a 2048-bit RSA key pair
openssl genrsa -out $HOME/.oci/cloudsavvy_key.pem 2048
openssl rsa -pubout -in $HOME/.oci/cloudsavvy_key.pem -out $HOME/.oci/cloudsavvy_key_public.pem

# Show the fingerprint OCI will display for this key
openssl rsa -pubout -outform DER -in $HOME/.oci/cloudsavvy_key.pem | openssl md5 -c

Check the fingerprint before continuing

The fingerprint shown in the OCI Console must match the key pair you are holding. If you have generated more than one key it is easy to upload one public key and then paste a different private key — the two no longer match and the connection is rejected. This is the most common reason Oracle Cloud onboarding fails.

The key must have no passphrase

The connect form has no passphrase field. If your key has one, connect the tenancy first and then supply the key and its passphrase through Update API key on the Cloud Accounts page.

Step 2 — Grant read access

Create a group — CloudSavvyReaders below — put the API user in it, and attach this policy under Identity → Policies.

Allow group CloudSavvyReaders to read all-resources in tenancy
Allow group CloudSavvyReaders to read usage-reports in tenancy

What each statement covers

Both lines matter and they cover different things. Each is here because CloudSavvy makes a call that needs it — nothing is asked for on the chance it might be useful later.

read all-resources in tenancy

Lets CloudSavvy see your compute instances, block volumes and backups, public IPs, load balancers, buckets, security lists and their utilisation metrics. Without it, resources and waste findings stay empty. It covers every read CloudSavvy makes except the cost one: the tenancy and compartment lookups, the Resource Search query that produces the inventory, the Core, Load Balancer and Object Storage calls that fill it in, and the Monitoring queries behind idle detection.

read usage-reports in tenancy

Lets CloudSavvy read your spend, through one daily per-resource query against the Usage API. Without it everything is listed but nothing is costed. Usage is not part of all-resources, so the first line does not cover it.

Also needed — verify in your tenancy

Two things this guide cannot settle for you, because they depend on Oracle's own policy reference and on how your tenancy is organised. Both are quick to check, and neither is guessed at above.

The usage resource type. If the Console rejects the second line, check the resource-type name Oracle's IAM policy reference gives for the Usage API in your realm and use that spelling. The statement is still needed; only its wording is Oracle's to fix.
Scoping to a compartment. The connect form takes an optional compartment, and the first line can be narrowed to it. The usage read cannot: CloudSavvy queries the Usage API against the tenancy, so scoping that statement to a compartment leaves every cost empty.

Every permission above is a read. CloudSavvy never creates, modifies or deletes anything in your tenancy.

What you'll need for onboarding

The connect form asks for these, in this order. All except the private key are identifiers rather than secrets.

Tenancy OCID — Profile menu → Tenancy. Begins ocid1.tenancy.
Tenancy name (optional) — a label for your own benefit, shown on the Cloud Accounts page.
User OCID — Profile menu → User settings. Begins ocid1.user.
API key fingerprint — shown next to the API key after you upload it.
Private key (PEM) — the whole file, including the BEGIN and END lines.
Home region — for example us-ashburn-1 or ap-mumbai-1.
Compartment OCID (optional — scopes the read) — leave it blank to read the whole tenancy.

Removing access

Removing the tenancy in CloudSavvy deletes the stored private key, but the key pair itself stays valid in OCI until you remove it. Delete the API key from the user under User settings → API keys as well, and remove the user from the group if it exists only for CloudSavvy.