Skip to main content

More Info:

API signing keys should be rotated every 90 days. Regular rotation limits the window of exposure if a key is compromised and ensures cryptographic material stays current

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • 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 SP 800-171
  • NYDFS 23 NYCRR 500
  • Reserve Bank of India (RBI) Master Direction – Information Technology Framework
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Below are the console-based steps to remediate “OCI IAM API Keys Should Be Rotated Every 90 Days” by rotating a user’s API key and aligning with monitoring.

1. Identify which API keys need rotation

  1. Sign in to the OCI Console.
  2. Go to Identity & SecurityIdentityUsers.
  3. Click the specific user.
  4. In the user details, go to the API Keys tab.
  5. Note the Created date of each key. Any older than 90 days should be rotated.

2. Create a new API key for the user

  1. Stay on the same user’s API Keys tab.
  2. Click Add API Key.
  3. Choose Generate API Key Pair (recommended for simplicity):
    • The console generates a public/private key pair.
    • Click Download Private Key and save it securely (this is your only chance).
  4. Click Add to register the new key.
  5. Copy and save:
    • Fingerprint
    • Tenancy OCID
    • User OCID
    • API endpoint region (for CLI/SDK config later).
If you already have your own key pair, choose Upload Public Key and upload the public key instead.

3. Update applications / tools to use the new key

Wherever the old key is used (CLI config, SDKs, automation scripts, CI/CD):
  1. Update the configuration with:
    • New private key file path
    • New fingerprint
    • Same user OCID and tenancy OCID (unless you changed the user/tenancy)
    • Same region
  2. Test that:
    • oci iam compartment list (or another simple call) works for that user.
    • Applications using the key can still access needed resources.
Ensure everything is working before deleting the old key.

4. Delete the old API key

  1. Back in Identity & SecurityIdentityUsersuserAPI Keys.
  2. Identify the old key (by Created date or fingerprint).
  3. Click the three dots (⋯) next to the old key.
  4. Click Delete and confirm.
That fully rotates the key: new key in use; old key removed.

5. Set up / confirm monitoring for 90‑day rotation

To continuously detect this issue:
  1. Go to Cloud Guard (Identity & Security → Cloud Guard).
  2. Make sure Cloud Guard status is Enabled.
  3. Under Detector Recipes, open your active recipe (often the default Oracle-managed one, or your clone).
  4. Find the detector for IAM API key age / rotation (name varies but is typically under IAM or Identity security checks).
  5. Ensure it is:
    • Enabled
    • Severity set appropriately (e.g., High/Medium)
  6. (Optional) Under Responder Recipes, configure responders/notifications (email, pager, etc.) for this detector so you are alerted when a key is older than 90 days.

Ongoing practice: Repeat this process for all users with API keys; integrate it into a 90‑day rotation schedule, or rely on Cloud Guard alerts to trigger rotation.
Below are the minimal, CLI-focused steps to remediate “OCI IAM API Keys Should Be Rotated Every 90 Days” by rotating the keys and (optionally) setting up monitoring.

1. Prerequisites

  • OCI CLI installed and configured (oci setup config already done).
  • You know the User OCID whose API keys you want to rotate (could be yourself or a service user).
If you don’t know the user OCID (for your own account):

2. List Existing API Keys and Check Age

If any timeCreated is older than 90 days, you should rotate that key.

3. Generate a New RSA Key Pair Locally


4. Upload the New Public Key to OCI (Create New API Key)

This returns the new key-id which you can record for reference.

5. Update Your OCI CLI Config to Use the New Private Key

Edit your OCI config file (typically ~/.oci/config):
Update (or add) the profile you use to include the new key:
You can get fingerprints for keys via:
Test that CLI works with the new key:

6. Delete the Old API Key

List keys again to find the old key-id:
Delete the old key:
Or using key-id:

7. (Optional) Monitoring: Detect Keys Older Than 90 Days

You can periodically run a script using OCI CLI to detect keys older than 90 days and send alerts via Monitoring/Notifications.Example: list keys with creation time filter using JMESPath and date comparison in a shell script:
You can run this via a scheduled job (cron, OCI DevOps pipeline, or external scheduler) and alert when old keys are found.
These steps remediate the finding by rotating OCI IAM API keys via OCI CLI and optionally allow you to monitor and alert on keys older than 90 days.
Below is a simple, practical way to monitor and enforce a “rotate every 90 days” policy for OCI IAM API keys using Python and the OCI SDK.You’ll:
  1. Use the OCI Python SDK to list users and their API keys
  2. Calculate key age
  3. Flag keys older than 90 days (log, email, or push metrics)
  4. Optionally, auto-delete old keys (if your process supports it)

1. Prerequisites

  1. Install the OCI Python SDK:
  1. Create/verify an OCI config file (usually ~/.oci/config) with a profile:
  1. Make sure the user or instance principal running the script has these IAM permissions in a policy (at least at tenancy or compartment scope you care about):

2. Python Script: Detect API Keys Older Than 90 Days

This script:
  • Lists all IAM users
  • Lists each user’s API keys
  • Flags keys older than 90 days
  • (Optional) deletes them if AUTO_DELETE_OLD_KEYS = True
Notes:
  • time_created is returned in UTC with timezone.
  • For IAM API keys, key_id is the fingerprint and is used as fingerprint in delete_api_key.
  • Keep DRY_RUN=True while testing to avoid accidental deletion.

3. Integrating with “Monitoring”

Pick how you want to consume this check:

Option A: Run on a Schedule (cron / CI)

Run the script daily via cron on a bastion server or in a CI pipeline (GitHub Actions, Jenkins, etc.):Example cron (run every night at 01:00):
You can then:
  • Send email/Slack when [STALE] appears in log.
  • Or export output as JSON and push to a logging system.

Option B: Use an OCI Function + Logging / Notifications

  1. Package this script logic as an OCI Function (Python runtime).
  2. Write stale key findings to:
    • OCI Logging (using logging module)
    • or push notifications via OCI Notifications to email/Slack.
High-level steps:
  • Create function application in your compartment.
  • Deploy Python function with above logic (adapt to use instance principal or resource principal).
  • Create a scheduled job using OCI Events + Functions (Event rule with schedule, e.g., cron(0 1 * * ? *)).
  • Function writes to Logging or calls Notifications.

4. (Optional) Enforcing Rotation, Not Just Deletion

To truly “rotate” instead of just delete, you need a process:
  1. Notify user whose keys are > N days old.
  2. User (or automation) creates a new key pair and uploads public key or uses CLI to create new API key.
  3. Verify new key works.
  4. Script deletes old key once new is in place and younger than threshold.
You can enhance the script to:
  • Only delete keys if user has at least one “young” key.
  • Or send email only, and have manual rotation performed.

5. Summary

  • Use the OCI Python SDK (oci.identity.IdentityClient) to list users and list_api_keys.
  • Compare time_created to now - 90 days.
  • Log/alert or auto-delete keys older than 90 days.
  • Schedule the script via cron, CI, or OCI Functions/Events to continuously monitor and enforce your rotation policy.