cloud-iam-hardening

Cloud IAM Hardening

Purpose

Identity is the perimeter in cloud environments — network controls help, but the vast majority of real-world cloud breaches trace back to over-permissioned roles, leaked long-lived credentials, or a human/service account with far more access than its job requires. IAM hardening is not a one-time setup step; it is a continuous discipline of shrinking permissions to what's actually used, replacing static credentials with short-lived federated tokens, and reviewing access on a cadence. This skill applies across AWS IAM, Azure RBAC/Entra ID, and GCP IAM, since the underlying failure modes (privilege creep, standing admin access, long-lived keys) are identical even though the primitives differ.

When to use

• Reducing an over-broad policy (e.g. AdministratorAccess, Owner, roles/editor) down to least privilege for a specific workload or team.
• Setting up CI/CD pipelines (GitHub Actions, GitLab CI, Azure DevOps) to authenticate to cloud APIs without storing static access keys/service account keys as secrets.
• Investigating "who can do X" or "why does this role have this permission" during an incident or audit.
• Implementing break-glass emergency access that bypasses normal SSO/MFA flows only when genuinely needed, with full audit logging.
• Running a quarterly or post-incident access review to find unused permissions, stale credentials, or orphaned service principals.
• Responding to a cloud security posture finding like "N IAM users have console access keys older than 90 days" or "M service accounts have organization-level Owner."

Prerequisites & environment

• Read access to the relevant IAM surface: AWS IAM Access Analyzer / CloudTrail, Azure AD sign-in + audit logs / Entra Permissions Management, or GCP IAM Recommender / Policy Analyzer — these tools generate the "what's actually used" data that least-privilege redesigns depend on; don't guess permissions from documentation alone.
• For CI/CD federation: the CI platform must support OIDC token issuance (GitHub Actions, GitLab CI ≥ 15.7, CircleCI, Azure DevOps all do natively as of 2024).
• Terraform ≥ 1.5 (or the cloud-native IaC of choice) if policies are managed as code — strongly recommended over console-managed IAM once past a handful of roles.
• Organizational agreement on a break-glass process owner and an alerting destination (e.g. a PagerDuty escalation) before implementing break-glass access, so its use is always followed up on.