Rotating cloud credentials

Scope: AWS, GCP, Azure, Kubernetes — when you suspect creds on your machine or in CI were exfiltrated.

Authoritative playbooks (use these as the source of truth)

• AWS Customer Playbook Framework — Compromised IAM Credentials — the official AWS-blessed incident response playbook.
• AWS Security Incident Response User Guide — the framework.
• AWS Docs — Secure access keys.
• AWS re:Post — Resolve unauthorized activity in AWS accounts.
• Datadog Security Labs — Known compromised IAM user access key — detection guidance.
• GCP — Investigate suspicious activity.
• Azure — Investigate sign-in risk.

Do this first (60 seconds)

For each cloud you use:

• AWS: console.aws.amazon.com/iam/home#/users → your user → Security credentials → Make inactive on every access key. (Don't delete yet — you may need the access key ID for log forensics.)
• GCP: console.cloud.google.com/iam-admin/serviceaccounts → revoke every key.
• Azure: portal.azure.com → Microsoft Entra ID → App registrations → revoke client secrets.
• Kubernetes: rotate service account tokens or kubeconfig credentials — see below.

Inactivating before deleting is important: an attacker spinning up resources leaves logs tied to the access key ID, which you want for forensics.

If AWS detects your key was exposed (e.g., on GitHub), they auto-attach the AWSCompromisedKeyQuarantineV2 managed policy to the affected IAM user. Check for that policy first — if it's there, AWS has already partially contained the incident.

Triage — what could the attacker have done?

Cloud creds with admin scope can cost real money very fast (crypto miners, model training runs) and exfiltrate data. Even read-only creds can dump customer PII.

Rotate

AWS

# List access keys for the affected IAM user
aws iam list-access-keys --user-name YOUR_USER

# Create a new key (write it down — only shown once)
aws iam create-access-key --user-name YOUR_USER

# Update your local config
aws configure  # or edit ~/.aws/credentials directly

# Delete the old key (once new one is confirmed working)
aws iam delete-access-key --user-name YOUR_USER --access-key-id AKIA_OLD

Also:

• MFA: confirm MFA is enabled on your IAM user.
• Session tokens / SSO: if you use AWS SSO or IAM Identity Center, aws sso logout.
• Switch to short-lived creds. Prefer SSO / aws sts assume-role over long-lived access keys. For CI, prefer GitHub OIDC ↔ AWS over stored keys.

GCP

# List service account keys
gcloud iam service-accounts keys list --iam-account=SA@PROJECT.iam.gserviceaccount.com

# Delete each key
gcloud iam service-accounts keys delete KEY_ID --iam-account=SA@PROJECT.iam.gserviceaccount.com

# Sign out user creds locally
gcloud auth revoke --all
rm -rf ~/.config/gcloud
gcloud auth login
gcloud auth application-default login

Prefer Workload Identity Federation over downloaded SA JSON keys.

Azure

# List service principals
az ad sp list --display-name "YOUR_SP_NAME"

# Reset client secret
az ad sp credential reset --id <appId>

# Sign out
az logout
rm -rf ~/.azure
az login

Use Workload Identity Federation for Azure with GitHub Actions instead of long-lived client secrets.

Kubernetes

# Find what creds your kubeconfig holds
kubectl config view --raw | grep -E "token|certificate"

# Rotate based on cred type:
# - exec'd cloud SA token: rotate the underlying cloud SA (see above)
# - long-lived SA token: kubectl delete secret <sa-token>; recreate
# - client cert: re-issue from your cluster CA
# - kubeconfig file: delete, regenerate, redistribute

rm ~/.kube/config
# Then re-obtain from your cluster (e.g., aws eks update-kubeconfig)

Audit damage

Pull the audit log for the time window. Look for unfamiliar resources, IAM/role changes, and unusual API calls.

# AWS — CloudTrail recent events
aws cloudtrail lookup-events --start-time 2026-05-10 --max-items 100 --output table

# AWS — billing anomaly (the loudest signal)
# Check Cost Explorer for spend spikes; new EC2/SageMaker/Bedrock is usually crypto/AI abuse.

# GCP — admin activity logs
gcloud logging read 'logName="projects/PROJECT/logs/cloudaudit.googleapis.com%2Factivity"' \
  --limit 100 --freshness=7d

# Azure — Activity Log
az monitor activity-log list --start-time 2026-05-10 --max-events 100 -o table

For each unexpected resource: document → delete → disclose if customer data was touched.

Prevention going forward

Hard rules:

• No long-lived cloud keys on developer machines. SSO + role assumption only.
• No long-lived keys in CI. OIDC federation for GitHub Actions / GitLab / etc.
• Keys that must exist (legacy systems): 1Password CLI or AWS Secrets Manager — never ~/.aws/credentials plain text.
• Set spend alerts. A $500/day spike on a usually-quiet account is your loudest intrusion signal.
• Subscribe to AWS GuardDuty / GCP Security Command Center / Azure Defender for Cloud — they detect known-bad behaviors (impossible-travel logins, mass S3 reads, etc.) automatically.

→ prevention/credential-hygiene.md for the broader credential model.