Back to Cookbook

Access Auditor

Find the 200 orphaned accounts with admin privileges nobody knew about

Audits user accounts, service accounts, and access keys across your cloud and identity providers. Finds orphaned accounts, unused access keys, over-privileged service accounts, and users who left months ago but still have access.

House RecipeWork5 min

INGREDIENTS

🐙GitHub💬Slack

PROMPT

Create a skill called "Access Auditor". Audit access and identity across cloud infrastructure: AWS IAM: 1. `aws iam list-users` — list all users and their last login date 2. `aws iam list-access-keys` for each user — find unused keys (90+ days) 3. `aws iam list-roles` — find roles with admin policies or wildcard permissions 4. Check for root account access keys (should never exist) 5. Check MFA status for all users 6. Check password age and rotation policy compliance Kubernetes RBAC: 1. List all ClusterRoleBindings and RoleBindings 2. Find bindings to subjects that reference non-existent users or groups 3. Identify overly broad ClusterRoles (cluster-admin granted too widely) 4. Find ServiceAccounts with excessive permissions Cross-reference: - If an employee list is provided, identify accounts that don't match any current employee - Flag accounts with admin access that haven't been active in 60+ days Generate remediation steps for each finding, categorized by risk.

How It Works

People leave, roles change, but access permissions persist forever unless

someone explicitly removes them. This skill finds the gaps before an

auditor (or an attacker) does.

What You Get

  • User account audit: who has access, what level, when last active
  • Orphaned accounts: users who no longer appear in your identity provider
  • Stale access keys: AWS access keys unused for 90+ days
  • Over-privileged service accounts: service accounts with admin-level access
  • MFA status: users without MFA enabled
  • Access key rotation compliance: keys older than your policy threshold
  • Offboarding checklist generation for departing employees

Setup Steps

  1. Ensure your Claw has read access to AWS IAM, K8s RBAC, or your identity provider
  2. Optionally provide an employee directory export for orphan detection
  3. Run the audit and review findings
  4. Generate remediation tickets for each finding

Tips

  • Cross-reference AWS IAM users with your identity provider to find orphans
  • Service accounts are the most commonly forgotten — review them quarterly
  • Access keys older than 90 days should be rotated as a standard policy
  • Root account access keys should never exist in AWS
  • Generate the offboarding checklist before someone leaves, not after
Tags:#security#iam#audit#devops