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 compromisedRisk Level
MediumAddress
Compliance, SecurityCompliance 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
Remediation
Using Console
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.
Summary of console actions:
1. Identify Your Admin Users
In OCI, “admin” users are typically those in groups that have powerful policies likemanage all-resources in tenancy.- In the OCI Console, go to: Identity & Security → Identity → Users
- 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.
Administrators or similar group, you can just list that group’s members:- Go to Identity & Security → Identity → Groups
- Click your admin group (e.g.,
Administrators). - Go to the Members tab and see all admin users.
2. Remove API Signing Keys from Admin Users
For each admin user:- Go to Identity & Security → Identity → Users.
- Click the admin user.
- Go to the API Keys tab.
- For each API key listed:
- Click the Actions (⋯) menu next to the key.
- Click Delete.
- Confirm the deletion.
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)
- Go to Identity & Security → Cloud Guard.
- If not enabled, click Enable Cloud Guard.
- Choose:
- Target: usually your tenancy.
- Detector recipes: use the Oracle-managed recipes to start.
4.2 Use or Customize an IAM Detector
- In Cloud Guard, go to Detector Recipes.
- Select the IAM Detector Recipe associated with your target.
- 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.
- 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.
- Attach the custom IAM detector recipe to your Cloud Guard target.
5. (Optional) Add Automatic or Guided Remediation (Responder)
If you want Cloud Guard to help remediate:- Go to Cloud Guard → Responder Recipes.
- Create a custom responder recipe (copy from Oracle-managed if needed).
- 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).
- Attach the custom responder recipe to your Cloud Guard target.
Summary of console actions:
- Identify admin users (groups with
manage all-resourcesor 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.
Using CLI
Using CLI
Below is a concise, CLI-focused way to remediate “OCI IAM Admin Users Should Not Have API Signing Keys” by:
List policies in the root compartment (tenancy):Look for policy statements like:
Capture the user OCIDs you want to check (admin users).You can also assemble an array:
Review this output. Decide which keys must be removed (typically all keys for admin users to satisfy the control).
If you’re satisfied removing all keys for all admin users, you can script it:
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.
- Identifying admin users.
- Listing their API signing keys.
- Deleting those keys.
- You have OCI CLI configured (
oci setup configdone). - You have tenancy OCID available.
- “Admin users” = users in groups that effectively grant
manage all-resourceson the tenancy or equivalent broad admin policies.
1. Identify Administrator Groups
First, find groups with admin‑level policies.Allow group <GroupName> to manage all-resources in tenancy- Or any equivalent that gives broad admin rights.
2. List Users in Admin Groups
For each admin group, list users:3. List API Signing Keys for Each Admin User
For each admin user, list their API keys:4. Delete API Signing Keys for Admin Users
To delete a specific key by itskey-id: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 deletefor admin users automatically.
- Calls
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.
Using Python
Using Python
Below are concrete steps and a Python example using the OCI SDK to:
Common examples of Admin policies:You will:
- Find IAM users with Admin privileges
- Check if they have API signing keys
- Optionally delete those API keys (remediation)
- “Admin users” = users who get
manage all-resourcesontenancy(or equivalent). - You have:
- OCI tenancy with IAM enabled
- API signing config set up locally (
~/.oci/config) or environment variables ociPython 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:
- List all policies in the root compartment.
- Parse their statements.
- Identify those granting:
manage all-resources- at
tenancy(or root compartment)
2. Monitoring logic (high level)
- Get the tenancy OCID.
- List all groups and policies in the root compartment.
- From policies, extract groups that have
manage all-resourceson tenancy. - For each such “Admin group”:
- List group members (users).
- For each “Admin user”:
- List user API keys.
- If keys exist → violation.
- (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
- Deploy as a scheduled job:
- Use an OCI Functions function or a Compute instance + cron to run the script periodically.
- Run in DRY_RUN = True to:
- Log non-compliant users and keys.
- Send alerts (e.g., via OCI Notifications, email, Slack, etc.).
- Once processes are agreed with security/operations:
- Switch to
DRY_RUN = Falseto automatically remediate by deleting keys.
- Switch to
5. Hardening / production tips
- Tighten the
is_admin_policy_statementlogic 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.)
Using Terraform
Using Terraform
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.
