Skip to main content

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 scale

Risk Level

Medium

Address

Compliance, Security

Compliance 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

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.

1. Identify policies that reference users directly

  1. Sign in to the OCI Console.
  2. Open the Navigation MenuIdentity & SecurityIdentityPolicies.
  3. Select the relevant Compartment (top-left compartment picker).
  4. 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> ...
These are the ones to fix.

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”):
  1. Navigation MenuIdentity & SecurityIdentityGroups.
  2. Click Create Group.
  3. Enter:
    • Name: e.g., monitoring-admins
    • Description: e.g., Group for users who manage OCI Monitoring
  4. Click Create.

3. Add users (who had direct policy grants) into the group

  1. Still under Groups, click the group you created (e.g., monitoring-admins).
  2. Go to the Users tab.
  3. Click Add User to Group.
  4. Select each user that previously appeared in user-specific policy statements.
  5. Click Add.
Repeat until all affected users are included.

4. Update the policy statements to use the group instead of users

For each policy that referenced users directly:
  1. Navigation MenuIdentity & SecurityIdentityPolicies.
  2. Select the compartment, then click the relevant policy.
  3. Click Edit Policy Statements (or Edit).
  4. In the statements, replace lines like:
    • From:
    • To:
    Do this for all statements that use user <username>; convert them to group <group-name> with equivalent verbs (inspect/read/use/manage) and resources (monitoring-family, alarms, metrics, etc.).
  5. 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:
  1. Sign in to the console.
  2. Go to Observability & ManagementMonitoringService Metrics or Alarms.
  3. 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.
To remediate “OCI IAM Policies should grant permissions to groups, not users” using OCI CLI, you basically need to:
  1. Find policies that reference specific users in their statements.
  2. Create/choose an IAM group.
  3. Add those users to the group.
  4. Create equivalent policies for the group.
  5. Remove or edit user-targeting policies.
Below is a minimal, step‑by‑step CLI workflow.

0. Prerequisites

  • OCI CLI installed and configured (oci setup config done).
  • 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):
For each policy OCID, get the details:
Look for statements like:
or any 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:
Capture the group OCID from the output (data.id).

3. Add Users to the Group

For every user referenced in Allow user <user_name> ... statements:
  1. Get the user OCID:
  2. Add that user to the group:

4. Construct Equivalent Group-Based Policy Statements

For each user-based statement:
change it to:
Keep the verbs, resource types, and compartments intact; only swap 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:
  1. Prepare a JSON file group-policy-statements.json:
  2. 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 statements to an empty list ("statements": []), then update:
(Or better: delete the policy once you are sure you don’t need it.)

7. Verify Effective Access

Use oci as one of the affected users (via a user-specific profile in your ~/.oci/config):
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.
Below is a practical way to:
  1. Detect IAM policies that grant permissions directly to users instead of groups, and
  2. Remediate them using Python + OCI SDK (move those permissions to groups and update policies).

1. Conceptual Remediation Steps (OCI Console / API)

  1. Identify bad policies
    Find IAM policies whose statements contain:
    • ALLOW user <name> ... or
    • ALLOW any-user ... (if applicable for your environment).
  2. 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.
  3. Optionally:
    • Tag or record which policies were modified.
    • Re-run check to confirm there are no remaining user-based statements.

2. Python Setup

Configure ~/.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.

If you provide examples of your current policy statements, I can adjust the regex and rewrite logic to match them exactly.
Changing 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.