| name | oraclecloud-security-basics |
| description | Master OCI IAM policy syntax, common policy patterns, and API key management.
Use when writing IAM policies, granting access to compartments, or managing API keys.
Trigger with "oraclecloud security basics", "oci iam policy", "oci policy syntax", "oci api key setup".
|
| allowed-tools | Read, Write, Edit, Bash(pip:*), Bash(oci:*), Grep |
| version | 1.7.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","oraclecloud","oci"] |
| compatibility | Designed for Claude Code |
Oracle Cloud Security Basics
Overview
OCI IAM policy syntax (Allow group X to manage Y in compartment Z) is the number one enterprise complaint. One wrong policy locks you out of your own resources. One missing verb and your automation silently fails with a 404 NotAuthorizedOrNotFound that looks like a missing resource. This skill is the IAM policy cheat sheet with tested patterns for common access scenarios.
Purpose: Write correct IAM policies, manage API keys securely, and understand the OCI permission model.
Prerequisites
- OCI Python SDK —
pip install oci
- OCI config file at
~/.oci/config with valid credentials (user, fingerprint, tenancy, region, key_file)
- Tenancy administrator access (to create policies) or membership in a group with
manage policies permission
- Python 3.8+
Instructions
Step 1: Understand the Policy Verb Hierarchy
OCI uses four verbs in ascending order of privilege. Each higher verb includes all lower verbs:
| Verb | Capabilities | Typical Use Case |
|---|
inspect | List resources, get metadata only | Auditors, read-only dashboards |
read | Inspect + get full resource details/contents | Monitoring tools, reporting |
use | Read + act on existing resources (start/stop, attach) | Developers, operators |
manage | Use + create, delete, move resources | Admins, automation service accounts |
Critical: use does NOT include create or delete. This trips up every new OCI team.
Step 2: IAM Policy Syntax
Every OCI policy statement follows this exact structure:
Allow <subject> to <verb> <resource-type> in <location> [where <conditions>]
Subject types:
group <group-name> — IAM user groupdynamic-group <dg-name> — resource principals (instances, functions)
