Infra Notes

IAM naming convention: make access reviews faster and safer

Build an IAM naming convention that exposes environment, system, access level, and ownership so access reviews require less guesswork.

Published · Updated

Cloud SecurityIAMAccess ReviewComplianceStandardization

Problem

Access reviews take too long because reviewers cannot determine the purpose, owner, or risk of IAM identities from their names.

Why it happens

Role names, permission sets, users, groups, and policies are created without a consistent naming pattern or ownership model. Reviewers then have to infer purpose from attached permissions instead of understanding it from the identity itself.

Recommended approach

Standardize IAM naming around environment, system, role, and access level. Make ownership and purpose visible from the name so reviewers can understand risk and intent quickly.

Naming pattern and review checklist

Example naming pattern:

text

<company>-<env>-<system>-<role>
<company>-prod-platform-admin
<company>-staging-app-readonly
<company>-audit-log-readonly

Access review checklist:

  • Who owns this role?
  • What system does it access?
  • Which environment does it affect?
  • Is it admin, write, or read-only?
  • Is it still needed?

Use this when

  • AWS IAM
  • GCP IAM
  • SSO permission sets
  • Kubernetes RBAC
  • Database access
  • Compliance reviews

Avoid this when

  • Very small personal labs
  • One-off temporary accounts with no review expectation

Extra context

Naming is not a cosmetic issue here. It directly affects review speed, approval quality, and the ability to defend access decisions during audits.

Design a useful IAM name

A reviewer should be able to infer four things without opening the policy document:

text

<environment>-<system>-<access-level>-<identity-type>
prod-payments-readonly-role
staging-platform-admin-permission-set
shared-security-audit-group

Do not encode volatile data such as a person's team name if ownership changes frequently. Put durable machine-readable attributes in the name and keep owner, ticket, expiry, and business purpose in tags or identity-governance metadata.

Separate access level from job title

Names such as developer, operations, or vendor do not explain effective privilege. Prefer explicit access levels:

  • readonly: view or list operations only
  • operator: approved operational changes without identity administration
  • deployer: release-oriented permissions
  • admin: privileged administration with stronger approval requirements
  • breakglass: emergency access with monitoring and short duration

The exact meanings must be documented. A consistent suffix is useless if every team interprets operator differently.

Migration workflow for existing identities

  1. Inventory roles, groups, users, policies, and permission sets
  2. Identify owner, environment, system, access level, last use, and dependencies
  3. Define the target name and migration method
  4. Create the replacement identity and test it with least privilege
  5. Move assignments and automation references
  6. Monitor for use of the old identity
  7. Disable, then remove it after the agreed observation period

Renaming can break trust policies, CI/CD variables, Kubernetes mappings, Terraform state, and application configuration. Treat it as a migration, not a cosmetic bulk edit.

Access review evidence

Export a review record containing identity name, unique ID, owner, effective permissions, assignments, last-used data, decision, reviewer, and timestamp. Names accelerate the review; they do not replace verification of actual permissions.

Common mistakes

  • Putting an employee name in a shared workload role
  • Using admin for several different privilege levels
  • Omitting the production/non-production boundary
  • Renaming without checking automation and trust-policy references
  • Assuming a well-named role is least privilege without reviewing its policies

References