Home / OCI

OCIRunbookAdvanced

Sev1: OCI API key, auth token or customer secret key leaked — revoke, investigate, recover

Respond to leaked OCI credentials. Identify the credential type, delete it, block the user if needed, search the Audit log for what was done with it, clean up, and move workloads to instance and resource principals.

Deepak Bhardwaj3 min read

Applies toOCI IAM (identity domains), API signing keys, auth tokens, customer secret keys, OCI Audit, OCI CLI 3.x

Credential types and what they unlock

Credential Looks like Used for
API signing key Private PEM + fingerprint aa:bb:... OCI CLI / SDK / Terraform
Auth token Random string OCIR (docker login), Swift API, some DB integrations
Customer secret key Access key + secret S3-compatible Object Storage API
SMTP credentials Username + password Email Delivery
Pre-authenticated request (PAR) URL with /p/<token>/ Direct Object Storage access

1. Find the owner

# API key: search users for the fingerprint
for u in $(oci iam user list --compartment-id $TENANCY --all --query 'data[].id' --raw-output | jq -r '.[]'); do
  oci iam user api-key list --user-id $u --query "data[?fingerprint=='aa:bb:cc:...'].{user:\"user-id\"}" --raw-output
done

# Customer secret keys and auth tokens per user
oci iam customer-secret-key list --user-id <user-ocid> --output table
oci iam auth-token list --user-id <user-ocid> --output table

2. Revoke now

oci iam user api-key delete --user-id <user-ocid> --fingerprint aa:bb:cc:... --force
oci iam customer-secret-key delete --user-id <user-ocid> --customer-secret-key-id <id> --force
oci iam auth-token delete --user-id <user-ocid> --auth-token-id <id> --force
oci os preauth-request delete --bucket-name <bucket> --par-id <par-id> --force

If you don't yet know which credential leaked, block the user (identity domain admin console → user → deactivate) — that stops every credential at once — and sort it out afterwards.

3. Investigate with Audit

oci audit event list --compartment-id $C --start-time 2026-10-17T00:00:00Z --end-time 2026-10-24T23:59:59Z --all \
  --query 'data[?"data"."identity"."principal-id"==`<user-ocid>`].{t:"event-time", e:"data"."event-name", ip:"data"."identity"."ip-address", res:"data"."resource-name"}' \
  --output table

Audit is per compartment; run it across compartments (include the tenancy root and child compartments), or use Logging Search over the _Audit log for a tenancy-wide query.

Look for:

  • CreateUser, AddUserToGroup, UploadApiKey, CreateAuthToken, CreateCustomerSecretKey (persistence)
  • CreatePolicy / UpdatePolicy
  • LaunchInstance with GPU or large shapes (crypto-mining)
  • CreatePreauthenticatedRequest, GetObject floods (data theft)
  • Disabling Cloud Guard or logging

4. Clean up and recover

  • Remove anything the attacker created; capture details first.
  • Issue new credentials to the legitimate workload — preferably not a user key (see below).
  • If data was accessed, involve your security, legal and privacy teams.

5. Get workloads off user credentials

Workload Use
Runs on OCI Compute Instance principals (dynamic group + policy)
Functions, OKE workloads, Data Science, DevOps Resource principals / OKE workload identity
CI outside OCI A dedicated service user with one API key, short rotation, tight policy 
oci os ns get --auth instance_principal     # test from an instance in the dynamic group

Prevent it next time

  • Cloud Guard enabled with responders and notifications.
  • Rotate remaining API keys regularly; alert on new key uploads via Events.
  • Secret scanning on repositories and pipeline logs.

Related fixes