More Info:
IAM policies should grant permissions to groups rather than individual users. Granting permissions directly to users bypasses group-based access control, making it harder to audit and manage access at scaleRisk Level
MediumAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- AWS Startup Security Baseline
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS AWS
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- Cloudanix Best Practice
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- GDPR
- HIPAA
- HITRUST CSF
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST
- NIST CSF
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- PCI
- Reserve Bank of India (RBI) Cyber Security Framework
- Reserve Bank of India (RBI) Master Direction – Information Technology Framework
- SOC2
- 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-based steps to remediate “OCI IAM Policies Should Grant Permissions To Groups Not Users” for IAM (including Monitoring) in OCI.
If you share an example of an existing user-based policy statement, I can give you the exact group-based replacement text for Monitoring.
1. Identify policies that reference users directly
- Sign in to the OCI Console.
- Open the Navigation Menu → Identity & Security → Identity → Policies.
- Select the relevant Compartment (top-left compartment picker).
- For each policy:
- Click the policy name.
- Check the Statements section for lines like:
Allow user <username> to manage monitoring-family in compartment <compartment-name>- or any
Allow user <username> ...
2. Create a group to replace direct user grants (if not already present)
If you don’t already have a suitable group (e.g., “Monitoring-Admins” or “Monitoring-Users”):- Navigation Menu → Identity & Security → Identity → Groups.
- Click Create Group.
- Enter:
- Name: e.g.,
monitoring-admins - Description: e.g.,
Group for users who manage OCI Monitoring
- Name: e.g.,
- Click Create.
3. Add users (who had direct policy grants) into the group
- Still under Groups, click the group you created (e.g.,
monitoring-admins). - Go to the Users tab.
- Click Add User to Group.
- Select each user that previously appeared in user-specific policy statements.
- Click Add.
4. Update the policy statements to use the group instead of users
For each policy that referenced users directly:- Navigation Menu → Identity & Security → Identity → Policies.
- Select the compartment, then click the relevant policy.
- Click Edit Policy Statements (or Edit).
-
In the statements, replace lines like:
- From:
- To:
user <username>; convert them togroup <group-name>with equivalent verbs (inspect/read/use/manage) and resources (monitoring-family,alarms,metrics, etc.). - From:
- Click Save Changes.
5. Remove or clean up any leftover user-based policies
- Ensure no policies (in any compartment or the root compartment) still contain
Allow user <username> ...unless there is a very specific, justified exception. - If you find leftover policies that only granted permissions to a user and have now been migrated to group-based statements, you can:
- Remove the user-specific statements, or
- Delete the entire policy if it is no longer needed.
6. (Optional) Verify Monitoring access via console
Have a member of the group:- Sign in to the console.
- Go to Observability & Management → Monitoring → Service Metrics or Alarms.
- Confirm they can perform the expected actions (view, create, edit alarms, etc.) appropriate to the level of access you granted.
If you share an example of an existing user-based policy statement, I can give you the exact group-based replacement text for Monitoring.
Using CLI
Using CLI
To remediate “OCI IAM Policies should grant permissions to groups, not users” using OCI CLI, you basically need to:
For each policy OCID, get the details:Look for statements like:or any
Capture the group OCID from the output (
change it to:Keep the verbs, resource types, and compartments intact; only swap
Or perform the relevant Monitoring/IAM calls the user normally needs (e.g., access to metrics, alarms, etc.) to ensure access is preserved via the group-based policy.
This process remediates the “user not group” IAM policy finding for OCI IAM/Monitoring using only OCI CLI.
- Find policies that reference specific users in their statements.
- Create/choose an IAM group.
- Add those users to the group.
- Create equivalent policies for the group.
- Remove or edit user-targeting policies.
0. Prerequisites
- OCI CLI installed and configured (
oci setup configdone). - You know:
- Your tenancy OCID
- The compartment OCID(s) where the policies live (root or sub‑compartment).
1. List Policies and Identify User-Based Statements
List policies in a compartment (root or otherwise):Allow user ... line. Those are the misconfigurations.2. Create (or Choose) a Group
If you already have an appropriate group, note its name/OCID and skip this step.Create a new group:data.id).3. Add Users to the Group
For every user referenced inAllow user <user_name> ... statements:-
Get the user OCID:
-
Add that user to the group:
4. Construct Equivalent Group-Based Policy Statements
For each user-based statement:user <user_name> → group <GROUP_NAME>.5. Create a New Policy for the Group (Preferred)
Instead of editing in place (which can be risky if reused), create a new policy in the same compartment:-
Prepare a JSON file
group-policy-statements.json: -
Create the policy:
6. Disable or Delete the Old User-Based Policy
When you confirm everything works (users in the group can still perform required actions), delete or disable the old policy.-
To delete:
-
To disable without deleting (edit statements to a no-op or empty set):
First fetch the full JSON:
Edit
statementsto an empty list ("statements": []), then update:
7. Verify Effective Access
Useoci as one of the affected users (via a user-specific profile in your ~/.oci/config):This process remediates the “user not group” IAM policy finding for OCI IAM/Monitoring using only OCI CLI.
Using Python
Using Python
Below is a practical way to:
Configure
If you provide examples of your current policy statements, I can adjust the regex and rewrite logic to match them exactly.
- Detect IAM policies that grant permissions directly to users instead of groups, and
- Remediate them using Python + OCI SDK (move those permissions to groups and update policies).
1. Conceptual Remediation Steps (OCI Console / API)
-
Identify bad policies
Find IAM policies whose statements contain:ALLOW user <name> ...orALLOW any-user ...(if applicable for your environment).
-
For each offending statement:
- Determine the user(s) referenced.
- Identify an appropriate group (existing or new) that should receive this permission.
- Add the user to the group (if not already in it).
- Rewrite the policy statement, replacing:
ALLOW user <user-name> ...
with
ALLOW group <group-name> ...
- Apply updated policy.
-
Optionally:
- Tag or record which policies were modified.
- Re-run check to confirm there are no remaining user-based statements.
2. Python Setup
~/.oci/config (or use instance principal / resource principal).Example ~/.oci/config:3. Python Script – Detect and Remediate
Notes/assumptions:- This script:
- Scans all compartments (or a specific root compartment).
- Looks for policies with
ALLOW user. - Creates or uses a target group for each user (pattern:
user-<username>-group) if no mapping is specified. - Adds the user to that group.
- Rewrites statements accordingly and updates the policy.
- Adjust naming, compartment scoping, and mapping logic to your environment.
4. How This Ties to “OCI IAM Monitoring”
If you’re feeding this into a monitoring / compliance pipeline:- Run this script regularly via:
- OCI Functions, OCI DevOps Pipeline, or a scheduled job (e.g., cron from an OCI Compute instance).
- Before remediation, you can:
- First run it in “report-only” mode (just detect and log without
update_policy) by:- Removing or gating the
identity.update_policy(...)call behind a flag.
- Removing or gating the
- First run it in “report-only” mode (just detect and log without
If you provide examples of your current policy statements, I can adjust the regex and rewrite logic to match them exactly.
Using Terraform
Using Terraform
statements on oci_identity_policy updates the policy in place and does not force resource replacement, but it does immediately change authorization behavior when applied.Verification with terraform plan should show the existing oci_identity_policy with its statements argument changing from Allow user ... entries to the new Allow group ... entries and no -/+ replacement of the resource itself.
