Skip to main content

More Info:

Administrator users should not have API signing keys. API keys for admin accounts increase the risk of privilege escalation if keys are leaked or compromised

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • AWS Well Architected Framework
  • 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
  • FedRAMP
  • GDPR
  • HIPAA
  • HITRUST CSF
  • ISO 27001
  • 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

Here’s how to remediate “OCI IAM Admin Users Should Not Have API Signing Keys” using the OCI Console, focusing on IAM and monitoring.

1. Identify Your Admin Users

In OCI, “admin” users are typically those in groups that have powerful policies like manage all-resources in tenancy.
  1. In the OCI Console, go to: Identity & Security → Identity → Users
  2. For each user you consider an “admin”:
    • Click the user name.
    • Go to the Groups tab.
    • Note any group that has admin-level policies, e.g.:
    • Any user in such groups should be treated as an admin for this control.
If you’re using a dedicated Administrators or similar group, you can just list that group’s members:
  1. Go to Identity & Security → Identity → Groups
  2. Click your admin group (e.g., Administrators).
  3. Go to the Members tab and see all admin users.

2. Remove API Signing Keys from Admin Users

For each admin user:
  1. Go to Identity & Security → Identity → Users.
  2. Click the admin user.
  3. Go to the API Keys tab.
  4. For each API key listed:
    • Click the Actions (⋯) menu next to the key.
    • Click Delete.
    • Confirm the deletion.
Repeat this for all admin users that should not have API signing keys.

3. (Optional) Restrict Future Use of API Keys for Admins

While OCI doesn’t have a direct toggle “disallow API keys,” you can reduce the risk by:
  • Using federated SSO (IdP) for admins so they don’t need local OCI user credentials.
  • Keeping admin access in separate groups and periodically auditing API keys for that group’s members (see section 4).

4. Set Up Monitoring / Detection in OCI (Cloud Guard)

If you’re using Cloud Guard for IAM monitoring, you can detect this issue when it happens again.

4.1 Enable and Configure Cloud Guard (if not already)

  1. Go to Identity & Security → Cloud Guard.
  2. If not enabled, click Enable Cloud Guard.
  3. Choose:
    • Target: usually your tenancy.
    • Detector recipes: use the Oracle-managed recipes to start.

4.2 Use or Customize an IAM Detector

  1. In Cloud Guard, go to Detector Recipes.
  2. Select the IAM Detector Recipe associated with your target.
  3. Look for a detector rule related to:
    • “Users with high-privilege policies with API keys” or similar IAM/API-key related rule. Names may vary by tenancy/version.
  4. If available:
    • Make a copy of the Oracle-managed recipe (you cannot edit an Oracle-managed one directly).
    • In your custom IAM detector recipe, enable the relevant rule and set:
      • Risk level (e.g., High).
      • Condition: ensure it applies to:
        • Users in groups with admin-level privileges.
  5. Attach the custom IAM detector recipe to your Cloud Guard target.
Now, whenever an admin user gets an API key, Cloud Guard will generate a Problem.

5. (Optional) Add Automatic or Guided Remediation (Responder)

If you want Cloud Guard to help remediate:
  1. Go to Cloud Guard → Responder Recipes.
  2. Create a custom responder recipe (copy from Oracle-managed if needed).
  3. Add or enable a responder rule for the corresponding IAM detector:
    • Example action: Notify (via email) or automatic Function that removes keys (requires custom function; console-only deletion is manual).
  4. Attach the custom responder recipe to your Cloud Guard target.
At minimum, set notifications so security/IAM admins are alerted when a new API key is added to an admin user.
Summary of console actions:
  • Identify admin users (groups with manage all-resources or similar).
  • For each admin user: Users → [User] → API Keys → Delete all keys.
  • Enable/Configure Cloud Guard IAM detector recipes to monitor for this condition going forward.
Below is a concise, CLI-focused way to remediate “OCI IAM Admin Users Should Not Have API Signing Keys” by:
  1. Identifying admin users.
  2. Listing their API signing keys.
  3. Deleting those keys.
Assumptions:
  • You have OCI CLI configured (oci setup config done).
  • You have tenancy OCID available.
  • “Admin users” = users in groups that effectively grant manage all-resources on the tenancy or equivalent broad admin policies.

1. Identify Administrator Groups

First, find groups with admin‑level policies.
List policies in the root compartment (tenancy):
Look for policy statements like:
  • Allow group <GroupName> to manage all-resources in tenancy
  • Or any equivalent that gives broad admin rights.
Collect the group names you determine are “admin groups”. Suppose they are:

2. List Users in Admin Groups

For each admin group, list users:
Capture the user OCIDs you want to check (admin users).You can also assemble an array:

3. List API Signing Keys for Each Admin User

For each admin user, list their API keys:
Review this output. Decide which keys must be removed (typically all keys for admin users to satisfy the control).

4. Delete API Signing Keys for Admin Users

To delete a specific key by its key-id:
If you’re satisfied removing all keys for all admin users, you can script it:

5. (Optional) Prevent Reintroduction

To reduce recurrence (useful for IAM Monitoring / continuous compliance):
  • Use IAM policies and process controls so that:
    • Admins primarily use federation (IdP/SAML) or ephemeral tokens rather than user API keys.
  • Use Cloud Guard / IAM Monitoring recipes to detect:
    • Any API key creation for users in admin groups.
  • Hook Cloud Guard detector → responder rule that triggers automation (e.g., OCI Function or script) that:
    • Calls oci iam user api-key delete for admin users automatically.

If you share how IAM Monitoring/Cloud Guard is currently reporting this finding (detector type / payload), I can give a CLI-based remediation script tailored to that detector output.
Below are concrete steps and a Python example using the OCI SDK to:
  1. Find IAM users with Admin privileges
  2. Check if they have API signing keys
  3. Optionally delete those API keys (remediation)
Assumptions:
  • “Admin users” = users who get manage all-resources on tenancy (or equivalent).
  • You have:
    • OCI tenancy with IAM enabled
    • API signing config set up locally (~/.oci/config) or environment variables
    • oci Python SDK installed: pip install oci

1. Define what “Admin user” means in your tenancy

In OCI, privileges come from policies, not from user flags.
Common examples of Admin policies:
You will:
  1. List all policies in the root compartment.
  2. Parse their statements.
  3. Identify those granting:
    • manage all-resources
    • at tenancy (or root compartment)
Then any user in the groups referenced by those policies is an “Admin user”.

2. Monitoring logic (high level)

  1. Get the tenancy OCID.
  2. List all groups and policies in the root compartment.
  3. From policies, extract groups that have manage all-resources on tenancy.
  4. For each such “Admin group”:
    • List group members (users).
  5. For each “Admin user”:
    • List user API keys.
    • If keys exist → violation.
  6. (Optional remediation) Delete the API keys for those users.

3. Python example: Detect & remediate

WARNING: Deleting API keys is destructive.
First run in read-only (dry-run) mode and log what would be deleted.
Only then enable the delete section.

4. How to use this for monitoring

  1. Deploy as a scheduled job:
    • Use an OCI Functions function or a Compute instance + cron to run the script periodically.
  2. Run in DRY_RUN = True to:
    • Log non-compliant users and keys.
    • Send alerts (e.g., via OCI Notifications, email, Slack, etc.).
  3. Once processes are agreed with security/operations:
    • Switch to DRY_RUN = False to automatically remediate by deleting keys.

5. Hardening / production tips

  • Tighten the is_admin_policy_statement logic to match your exact policies.
  • Maintain an allowlist of exceptions if needed.
  • Log actions (before/after) to Object Storage or a SIEM.
  • Run under a dedicated service principal (dynamic group + policy) with:
    (Adjust least-privilege as needed – at minimum, it needs to list users, groups, policies, and manage API keys.)
If you share your exact admin policy text, I can refine the parsing logic and permission policies.
Removing or editing an oci_identity_api_key resource for an admin user will cause Terraform to delete that API key from OCI; this is irreversible and the corresponding private key will no longer work.If any API signing keys were created for admin users outside Terraform, they cannot be removed via Terraform; delete them in the OCI Console under Identity & Security → Users → ADMIN_USERNAME → API Keys.For verification, terraform plan should show that all oci_identity_api_key resources associated with admin users are planned for destruction (or no longer exist in configuration), and only non-admin users retain oci_identity_api_key resources.