> ## Documentation Index > Fetch the complete documentation index at: https://help.nops.io/llms.txt > Use this file to discover all available pages before exploring further. # Oracle Cloud Infrastructure - Permissions & Resources > Complete reference of what the nOps stack creates in your Oracle Cloud tenancy, the permissions nOps uses, and where your cost data comes from. ## 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](https://help.nops.io/oci/integration-setup.md). The stack's source is public: [nops-io/terraform-oci-nops-integration](https://github.com/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 to read objects in tenancy usage-report allow 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 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 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..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..oraclecloud.com` `GET /n/bling/b//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..oraclecloud.com` `HEAD /n/bling/b//o/` | `endorse ... to read objects in tenancy usage-report` (`OBJECT_READ`) | On **Verify**, to confirm nOps can open a report file | | `GetObject` | `objectstorage..oraclecloud.com` `GET /n/bling/b//o/` | `endorse ... to read objects in tenancy usage-report` (`OBJECT_READ`) | On each daily load, to download report files | | `ListOrganizations` | `organizations..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-` | An IAM group for nOps | The policy grants access to a group, not to a single user | | **User** | `nops-cost-reports-` | 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-` | The three statements above | Lets the group read your cost reports and list your organization | `` 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. > [!NOTE] > > **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](https://github.com/nops-io/terraform-oci-nops-integration/releases/tag/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: 1. **In nOps:** delete the Oracle Cloud integration in [**Settings > Cloud Provider Integrations**](https://clara.nops.io/settings). nOps stops reading reports and deletes its private key. 2. **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. > [!WARNING] > > 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. *** ## Related Guides > [card] [Integration Setup](https://help.nops.io/oci/integration-setup.md) > > Step-by-step guide to connect your Oracle Cloud tenancy. > [card] [Cloud Provider Integrations](https://help.nops.io/platform/integrations.md) > > All the cloud providers and tools you can connect to nOps. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.