Oracle Cloud Infrastructure - Permissions & Resources

Overview

nOps connects to Oracle Cloud with read-only access to your cost and usage reports, plus a lookup of which Oracle organization your tenancy belongs to. That’s the whole integration: nOps does not read, create, or change any other resource in your tenancy. You grant this access by running the nOps Resource Manager stack during Integration Setup. The stack’s source is public: nops-io/terraform-oci-nops-integration.

Where Your Cost Data Comes From

Oracle writes your cost reports to Object Storage, in a bucket that Oracle owns, not in your tenancy:

Detail	Value
Tenancy	Oracle’s `usage-report` tenancy
Object Storage namespace	`bling`
Bucket	Your tenancy OCID
Folder nOps reads	`FOCUS Reports/` (one folder per day: `FOCUS Reports/YYYY/MM/DD/`)
Region	Your home region

What Oracle puts there:

A new FOCUS report about every 6 hours. A report can be up to 24 hours late.
Each report is a compressed CSV file (.csv.gz). Oracle splits large reports into several files of up to one million rows each.
Oracle keeps reports for one year, so nOps can load up to the last 12 months when you connect.
Non-metered tenancies get no cost reports.
In an Oracle organization, Oracle writes the reports for the whole organization in the parent tenancy, and they include every child tenancy. Connect the parent.

Because Oracle owns the bucket, you don’t create a bucket, an export, or any storage. You only give one nOps user permission to read it.

Permissions

The stack creates one policy, in your root compartment, with three statements:

define tenancy usage-report as ocid1.tenancy.oc1..aaaaaaaaned4fkpkisbwjlr56u7cj63lf3wffbilvqknstgtvzub7vhqkggq
endorse group <nops group> to read objects in tenancy usage-report
allow group <nops group> to inspect organizations-entity in tenancy

Statement	What it does	Why nOps needs it
`define tenancy usage-report as ...`	Gives Oracle’s report tenancy the short name `usage-report` inside your policy	The next statement has to name the tenancy it grants access to. The OCID is Oracle’s own, the same one Oracle uses in its cost report documentation
`endorse group <nops group> to read objects in tenancy usage-report`	Lets members of the nOps group list and read objects in Oracle’s report tenancy	To list your FOCUS report files and download them
`allow group <nops group> to inspect organizations-entity in tenancy`	Lets members of the nOps group list the Oracle organization your tenancy belongs to: its parent tenancy’s name and default subscription ID	To warn you when you connect a child tenancy, which shows little or none of its spend. It covers only `ListOrganizations`: nOps can’t see the other tenancies, subscriptions, or invitations, or change anything

The first two statements are the policy Oracle documents for reading cost and usage reports. Oracle only lets your tenancy read the bucket named after your own tenancy OCID, so this policy can’t reach any other customer’s reports. The policy must be in the root compartment. Oracle doesn’t accept define and endorse statements anywhere else. The read objects verb grants Oracle’s OBJECT_INSPECT and OBJECT_READ permissions only. It doesn’t include OBJECT_CREATE, OBJECT_OVERWRITE, or OBJECT_DELETE, so nOps can’t add, change, or delete report files.

API Calls nOps Makes

These are every Oracle Cloud API operation nOps calls. All of them are reads.

Operation	Endpoint	Allowed by	When nOps calls it
`GetNamespace`	`objectstorage.<home region>.oraclecloud.com` `GET /n/`	No policy needed: Oracle allows it for any signed-in user	On Verify, to confirm Oracle accepts the API key
`ListObjects`	`objectstorage.<home region>.oraclecloud.com` `GET /n/bling/b/<tenancy OCID>/o?prefix=FOCUS Reports/...`	`endorse ... to read objects in tenancy usage-report` (`OBJECT_INSPECT`)	On Verify, and on each daily load, to list report files
`HeadObject`	`objectstorage.<home region>.oraclecloud.com` `HEAD /n/bling/b/<tenancy OCID>/o/<report>`	`endorse ... to read objects in tenancy usage-report` (`OBJECT_READ`)	On Verify, to confirm nOps can open a report file
`GetObject`	`objectstorage.<home region>.oraclecloud.com` `GET /n/bling/b/<tenancy OCID>/o/<report>`	`endorse ... to read objects in tenancy usage-report` (`OBJECT_READ`)	On each daily load, to download report files
`ListOrganizations`	`organizations.<home region>.oci.oraclecloud.com` `GET /20230401/organizations`	`allow ... to inspect organizations-entity in tenancy`	On Verify, to check whether your tenancy is a child tenancy

Every request is signed with the nOps API key on the nOps user, and is sent over HTTPS to Oracle’s public endpoints for your home region. What nOps can’t do with this access:

See, create, change, or delete any resource in your tenancy (compute, storage, networks, databases, and so on)
Read objects in your own Object Storage buckets
Add, change, or delete report files in Oracle’s report bucket
Read another tenancy’s cost reports. Oracle only lets your tenancy read the bucket named after your own tenancy OCID
See the other tenancies, subscriptions, or invitations in your Oracle organization
Change billing settings, budgets, or subscriptions
Sign in to the Oracle Cloud console, or use any credential other than the API key

Resources the Stack Creates

All of these are created in the root compartment of your home region, whichever region you run the stack from.

Resource	Name	What it is	Why it’s needed
Group	`nops-cost-reports-reader-<suffix>`	An IAM group for nOps	The policy grants access to a group, not to a single user
User	`nops-cost-reports-<suffix>`	An IAM user, added to that group	The identity nOps signs in as
Group membership	—	Adds the nOps user to the nOps group	Gives the user the group’s access
User capabilities	—	Allows API keys only. Console password, auth tokens, customer secret keys, and SMTP credentials are all turned off	The user can’t sign in to the Console or hold any other credential
API key	—	Your nOps public key, added to that user	How nOps signs its requests. nOps holds the matching private key
Policy	`nops-cost-reports-policy-<suffix>`	The three statements above	Lets the group read your cost reports and list your organization

<suffix> is 6 hexadecimal characters that each stack picks once (for example nops-cost-reports-reader-3f9a1c). Running Apply again keeps it. A new stack picks a new one, so it never clashes with names an old stack left behind. Oracle requires an email on every user. The nOps user gets the email you enter in the stack, or yours if you leave it blank. Oracle may send it a welcome message, but the user still can’t sign in. Resource Manager also keeps the stack itself, with its job history, in the compartment and region you chose when you created it. Keep the stack: you use it later to update or remove everything it created.

Where to find them: in tenancies that use identity domains, the user and group are in the Default domain (Identity & Security > Domains > Default). In older tenancies, look under Identity & Security > Users and Groups. The policy is under Identity & Security > Policies, in the root compartment.

Stack Inputs and Outputs

You fill in two fields. Resource Manager fills in your tenancy, region, and user for you.

Input	Required	What it’s for
nOps public key	Yes	The key from the nOps Deploy step. The stack refuses a private key
Email for the nOps user	No	The nOps user’s email. Blank means the email of the administrator who runs the stack

When the apply job succeeds, its Outputs show:

Output	What it is
`nops_connection_code`	The code you paste into nOps
`nops_user_ocid`	OCID of the nOps user
`nops_group_name`	Name of the nOps group
`nops_api_key_fingerprint`	Fingerprint of the nOps API key. It matches the fingerprint shown in nOps
`home_region`	Your home region, where the resources were created

The Deploy to Oracle Cloud button always loads a pinned, tagged release of the stack (currently v1.0.2), so the code you read on GitHub is the code that runs.

How nOps Holds the Key

nOps creates an RSA key pair for each integration. You only ever see the public key.
The private key stays in an nOps encrypted secret store. It isn’t shown in the nOps app, sent to your browser, or included in the connection code.
The connection code the stack outputs holds no secret: your tenancy OCID, the user OCID, the key fingerprint, and your home region. nOps checks that the fingerprint matches its own key before it saves the code.
When you delete the integration in nOps, nOps deletes the private key.

Requirements

Requirement	Details
Who runs the stack	A tenancy administrator (a member of the Administrators group). Creating users, groups, and root-compartment policies needs this
Who runs the nOps wizard	An nOps admin
Tenancy type	A metered tenancy. Non-metered tenancies have no cost reports
Realm	The commercial realm (tenancy OCIDs that start with `ocid1.tenancy.oc1..`). Government and other realms aren’t supported yet
Oracle organizations	Connect the parent tenancy. Its reports include every child tenancy
Network setup	None. The reports are in Oracle’s bucket, and nOps reads them over Oracle’s public Object Storage endpoint for your home region

Security Model

Layer	Protection
Read-only policy	The only grants are `read objects` on Oracle’s report bucket and `inspect organizations-entity`. Nothing in your tenancy is readable or writable
Dedicated user and group	nOps gets its own user and group, so the policy can’t widen anyone else’s access, and removing them removes only nOps
API key only	The user’s capabilities allow API keys and nothing else: no console password, auth tokens, customer secret keys, or SMTP credentials
One key per integration	Each integration gets its own RSA-2048 key pair. The private key never leaves nOps’s encrypted secret store
No secret in the connection code	The code holds IDs and a fingerprint only. nOps rejects a code whose fingerprint doesn’t match its own key
Open source, pinned release	The stack is public Terraform, and the Deploy button uses a tagged release
Verification checks	nOps checks the key and report access before it marks the integration Active

Removing Access

Do both:

In nOps: delete the Oracle Cloud integration in Settings > Cloud Provider Integrations. nOps stops reading reports and deletes its private key.
In Oracle Cloud: open the nOps stack in Developer Services > Resource Manager > Stacks and click Destroy. This removes the policy, the user, its API key, and the group. You can then delete the stack.

Run Destroy before you delete the stack. Deleting a stack only removes Resource Manager’s record: the user, API key, group, and policy stay in your tenancy, and nOps keeps its access until you delete them yourself.

To cut off access immediately, delete the API key on the nOps user. nOps can’t sign in without it.

Integration Setup

Step-by-step guide to connect your Oracle Cloud tenancy.

Cloud Provider Integrations

All the cloud providers and tools you can connect to nOps.

Getting Started

Cloud provider integrations

Platform

Clara

Inform

AI

Operate

Optimize

Third-Party Integrations

Telemetry

Plugins

Portfolio Portal

Support

Oracle Cloud Infrastructure - Permissions & Resources

Overview

Where Your Cost Data Comes From

Permissions

API Calls nOps Makes

Resources the Stack Creates

Stack Inputs and Outputs

How nOps Holds the Key

Requirements

Security Model

Removing Access

Integration Setup

Cloud Provider Integrations

​Overview

​Where Your Cost Data Comes From

​Permissions

​API Calls nOps Makes

​Resources the Stack Creates

​Stack Inputs and Outputs

​How nOps Holds the Key

​Requirements

​Security Model

​Removing Access

​Related Guides

Integration Setup

Cloud Provider Integrations

Overview

Where Your Cost Data Comes From

Permissions

API Calls nOps Makes

Resources the Stack Creates

Stack Inputs and Outputs

How nOps Holds the Key

Requirements

Security Model

Removing Access

Related Guides