More Info:
Flag any IAM policy statement that grants broad verbs (manage/use) across all-resources to unconstrained groups. Wildcard administrative grants are the most critical vulnerability in identity perimeters.Risk Level
CriticalAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- Cloudanix Best Practice
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
Below are concise, console-focused steps to remediate the issue “OCI Governance Policies Should Not Grant Unrestricted Resource Access” for OCI Governance Monitoring, by tightening IAM policies to least privilege.
Or, further compartment scoped:Key principles:
If you share a current policy statement you’re using for Governance Monitoring, I can rewrite it to a least-privilege version you can paste directly into the console.
1. Identify the Problem Policies
- Sign in to the OCI Console.
- Open the navigation menu → Identity & Security → Policies.
- Ensure you are in the root compartment (or the compartment where your Governance policies are defined).
- Look for policies related to:
governance-monitoringgovernance-rule-family- or any policy used by your Governance Monitoring dynamic group or user group.
- Open each candidate policy and look for overly broad statements, such as:
Allow group <name> to manage all-resources in tenancyAllow dynamic-group <name> to manage all-resources in compartment <name>- or use of
managewithall-resourcesorinspect/useall-resourcesacross the tenancy.
2. Determine the Minimum Required Access
Verify what the Governance Monitoring service actually needs. In most environments, it only requires permissions to:- Read configuration / resources to evaluate governance rules.
- Write/read its own governance rule configurations and evaluation results.
governance-rule-family- Possibly
instance-family,object-family,vcn-family,tag-namespaces(for read/inspect only), depending on what the rules evaluate.
3. Edit the Policy to Remove Unrestricted Access
For each over-permissive policy:- From the Policies page, click the policy name.
- Click Edit Policy Statements.
- In the existing statements:
- Remove or rewrite lines that include:
all-resourcesin tenancywhen not needed (use specific compartments instead)managewhen lesser verbs likeinspect/read/usesuffice.
- Remove or rewrite lines that include:
Example: Bad Policy
Example: More Restrictive Replacement
Adjust based on what you actually need. A typical least-privilege pattern might look like:- Replace
manage all-resourceswith:inspect all-resourceswhere only read/visibility is needed, or- Resource-specific access (e.g.,
use governance-rule-family) where write is needed.
- Scope from
in tenancydown to the specific compartment(s) where Governance rules and targets are defined, if possible.
- After editing, click Save Changes.
4. Validate Governance Monitoring Still Works
- Go to Governance & Administration (or Security depending on tenant layout) → Governance Rules / Governance Monitoring.
- Run:
- A manual evaluation or
- Confirm scheduled evaluations run successfully and generate results.
- If evaluation fails with a permission error, revisit the policy and:
- Add narrowly scoped
inspectorusepermissions only for the exact resource-type mentioned in the error. - Avoid reverting back to
manage all-resources.
- Add narrowly scoped
5. Clean Up Any Redundant or Legacy Policies
- In Identity & Security → Policies, review for older, unused, or overlapping policies that still grant:
manage all-resources- Very broad
inspect all-resources in tenancynot needed by Governance.
- If confirmed unused:
- Either delete the policy or
- Comment out/replace the broad statements with more specific ones.
If you share a current policy statement you’re using for Governance Monitoring, I can rewrite it to a least-privilege version you can paste directly into the console.
Using CLI
Using CLI
Below is a practical, CLI‑only approach to identify and remediate overly permissive OCI IAM policies that violate “Governance Policies Should Not Grant Unrestricted Resource Access” (e.g., those used for Governance Monitoring / Cloud Guard or custom governance tooling).
If you know the compartment where governance/monitoring policies live, replace Look for statements that:
Still tenancy‑wide, but resource-specific, not
This gives you Or, if you can scope to a compartment (preferred):You can build this file from the backup, removing/replacing the problematic lines.If you also want to adjust the description to reflect that it’s restricted:
Verify that:
This shows policies where any statement contains
If you can share an example of the exact problematic policy statement you’re seeing for “OCI Governance Monitoring,” I can give you a minimal, concrete replacement statement set tailored to that use case.
1. Identify Overly Permissive Policies
Typical “unrestricted” patterns you want to flag:allow group <name> to manage all-resources in tenancyallow group <name> to inspect all-resources in tenancyallow group <name> to read all-resources in tenancy- Any
in tenancywith very broad verbs (manage) and wildcards.
1.1 List Policies in Your Tenancy
TENANCY_OCID with that compartment OCID.1.2 Inspect Each Policy’s Statements
For a specific policy:- Use
all-resources - Use
in tenancyinstead of a compartment - Grant
manageat too broad a scope
2. Decide the Correct Scope and Permissions
Before changing anything, decide:-
Which group truly needs what:
e.g.,governance-monitors. -
What access level is actually required for governance monitoring:
Commonly:inspectorreadon specific services (e.g.,audit-events-family,instances,volumes,buckets).- Rarely
manage, and only for specific resource types if automation is needed.
-
Where (tenancy vs compartment):
Prefer compartment scoping (in compartment <compartment_name>or using compartment OCIDs) unless full‑tenancy visibility is absolutely necessary.
all-resources.If you can limit to a compartment:3. Update the Policy via OCI CLI
You cannot partially edit a single statement; you replace the entire statement list.3.1 Save the Existing Policy (Backup)
name, description, statements, etc., in case you need to revert.3.2 Prepare a New Statements File
Create a JSON file containing the new, least‑privilege list of statements, for examplenew-statements.json:3.3 Apply the New Statements to the Policy
Extract the array from the JSON file and provide it tooci iam policy update:Note:jqis used here to pass a proper JSON array to--statements. Ensurejqis installed, or manually inline the array string.
4. Verify the Remediation
4.1 Confirm the New Statements
- No statement uses
all-resources in tenancy(unless contractually required and justified). - No statement uses overly broad
managewhere onlyinspect/readis needed.
4.2 Validate Governance Monitoring Still Works
- Trigger or run your governance monitoring / Cloud Guard / custom governance jobs.
- Check for any failures or missing visibility. If something fails, grant only the additional minimal actions required (e.g., add a specific
inspect <service-family>statement) and repeat.
5. Optional: Automate Detection of Unrestricted Policies
If you want to programmatically detect problematic policies with CLI +jq:all-resources in tenancy.You can similarly search for manage all-resources or other patterns.If you can share an example of the exact problematic policy statement you’re seeing for “OCI Governance Monitoring,” I can give you a minimal, concrete replacement statement set tailored to that use case.
Using Python
Using Python
Below is a concise approach to detect and then remediate overly permissive OCI policies (granting unrestricted resource access) using Python and the OCI SDK, suitable for use in a “Governance Monitoring” style workflow.
Use this for continuous Governance Monitoring (run as a scheduled job, send results to a log/Lambda/function, etc.).
Important:
1. What “Unrestricted Resource Access” Typically Looks Like
In OCI policy language, these are examples of overly broad statements:Allow group <name> to manage all-resources in tenancyAllow group <name> to inspect all-resources in tenancyAllow group <name> to use all-resources in tenancy- Same patterns but
in compartment <compartment-name>when the scope should be more granular.
2. Prerequisites
- Install SDK:
- Configure
~/.oci/configwith:
3. Python: Detect Policies With Unrestricted Resource Access
This script:- Lists all compartments
- Lists all IAM policies
- Flags statements with
all-resourcesorin tenancypatterns
4. Remediation Strategy (Conceptual)
You should not blindly auto-edit policies; you must understand what each group actually needs. General pattern:- Replace:
- With more specific:
-
For each flagged statement:
- Identify the
groupordynamic-group. - Identify what services/resources they truly require.
- Draft new statements that:
- Replace
all-resourceswith specific verbs and resource-types (e.g.instances,volume-family,virtual-network-family). - Replace
in tenancywith appropriatein compartment <name>.
- Replace
- Identify the
- Update the policy using the OCI SDK.
5. Python: Example of Updating a Policy
Below is a template that:- Reads an existing policy
- Rewrites statements using a mapping you control
- Updates the policy
rewrite_statement to encode your organization’s rules.- Test changes in a non-production tenancy or compartment first.
- Consider exporting policies (e.g., into Git) before bulk edits for rollback.
- For governance monitoring, usually you:
- Detect problematic policies automatically.
- Open tickets or send alerts to owners.
- Apply changes manually or through a controlled pipeline.
6. Integrating with “OCI Governance Monitoring”
To make this part of a governance solution:- Run the detection script periodically (OCI Functions, scheduled job, CI pipeline).
- Send findings to:
- OCI Logging / Object Storage, or
- A ticketing system (ServiceNow/Jira) via webhook, or
- Email/Slack via your automation layer.
- For high-risk cases (e.g.,
manage all-resources in tenancy), require manual review. - For low-risk patterns you’ve standardized, use the update script with a carefully controlled rule set.
Using Terraform
Using Terraform
TENANCY_OCIDwith the target tenancy OCID.GOVERNANCE_TENANCY_POLICY_DISPLAY_NAMEwith the existing governance tenancy policy display name.OPERATORS_GROUP,NETWORK_ADMINS_GROUP,READONLY_GROUPwith your actual OCI IAM group names.COMPARTMENT_NAME,NETWORK_COMPARTMENT_NAMEwith the exact compartment names/OCIDs you want to scope access to.
terraform plan should show the oci_governance_rules_tenancy_policy.GOVERNANCE_POLICY_NAME resource with a change only in its statements attribute, removing any manage all-resources in tenancy / use all-resources in tenancy lines and replacing them with the more scoped statements you defined.
