Free lesson · DevOps and Platform Engineering on AWS

Identity architecture for an engineering organisation

Easy8 min readawsdevopsplatform-engineering

Three Identity Problems

An engineering organisation has three, and they need different mechanisms.

The target state for all three is the same: zero IAM users and zero long-lived access keys. Every one of these has a temporary-credential path, and the presence of an access key anywhere in the estate is a finding rather than a design.

The Workforce Spine

Your identity provider is the source of truth. Identity Center is the AWS-side control plane.

graph LR
    IDP[Corporate IdP<br/>Entra ID, Okta, Google] -->|SCIM provisioning| IC[IAM Identity Center]
    IDP -->|SAML / OIDC auth| IC
    IC --> PS1[Permission set:<br/>ReadOnly]
    IC --> PS2[Permission set:<br/>Developer]
    IC --> PS3[Permission set:<br/>Admin]
    PS1 --> A1[Account A]
    PS2 --> A1
    PS2 --> A2[Account B]
    PS3 --> A3[Account C]
    IC --> CLI[CLI via aws sso login<br/>**temporary credentials**]

This diagram shows workforce identity architecture. A corporate identity provider such as Entra ID, Okta, or Google provisions users and groups into IAM Identity Center via SCIM, and handles authentication via SAML or OIDC. Identity Center defines permission sets such as ReadOnly, Developer, and Admin, and assigns them to accounts. Users access the CLI through aws sso login, receiving temporary credentials rather than long-lived keys.

SCIM provisioning is what makes joiner-mover-leaver work. A user disabled in the IdP loses AWS access without anyone remembering to do anything, and group membership changes flow through automatically. Without SCIM, deprovisioning is a manual step that will eventually be missed - and the person who left six months ago still has access.

Assign permission sets to groups, never to individuals. An assignment to a person is an assignment nobody reviews and nobody removes. Group membership is managed in the IdP where the joiner-mover-leaver process already lives.

Designing The Permission Set Catalogue

The part that decays without deliberate design.

Warning: Permission sets proliferate, and the pattern is predictable. Someone needs slightly more than Developer for a specific task, so a DeveloperPlusKinesis is created. Then DeveloperPlusKinesisAndBedrock. Within a year there are sixty permission sets, most used by one person, and nobody can say what any of them grant.

Design a small catalogue by job function and hold it. Five to ten permission sets is the target for most organisations:

Set	Grants
ReadOnly	View everything, change nothing - the default for most people
Developer	Full access within non-production
ProductionOperator	Read plus specific operational actions in production
SecurityAuditor	Read plus security service access, everywhere
BillingReader	Cost data
PlatformAdmin	Broad, few holders
BreakGlass	Emergency, alarmed, rarely used

The variation between teams belongs in ABAC conditions, not in more permission sets. A single Developer set whose policy is scoped by a session tag serves every team; forty TeamXDeveloper sets serve the same purpose and cannot be reasoned about.

Scope by account, not by policy, where you can. A Developer permission set granting broad access, assigned only to non-production accounts, is simpler and safer than a narrowly-scoped set assigned everywhere. The account boundary does the work - which is Topic 1's argument arriving in the identity design.

ABAC At Organisational Scale

Attribute-based access control lets one policy serve many teams, using attributes asserted at sign-in.

Identity Center can pass IdP attributes as session tags, available in policy conditions as aws:PrincipalTag:

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/team": "${aws:PrincipalTag/team}"
    }
  }
}

One policy, and each engineer can operate only their own team's resources.

Important: ABAC is only as reliable as your tagging, and that dependency is total. A resource with no team tag matches no principal and is operable by nobody; a resource tagged with the wrong team is operable by the wrong people.

Enforce tags at creation with an SCP before relying on ABAC for authorisation - Course 1 Module 13 Topic 5. An ABAC model layered over inconsistent tagging produces access failures that look like policy bugs and access grants that nobody intended.

Start with RBAC scoped by account and introduce ABAC where the team count makes per-team permission sets unmanageable. It is a scaling mechanism, not a starting point.

Delegated Administration And Permission Boundaries

Teams need to create IAM roles - for their Lambda functions, their tasks, their pipelines. Requiring a central team to create every role is a bottleneck that produces over-broad roles, because the request is batched and generous.

Permission boundaries let you delegate safely. A boundary is a maximum: a role created with a boundary attached can never exceed it, regardless of what policy is attached.

The delegation pattern:

1. Define a boundary policy - the maximum any team-created role may have
2. Grant teams iam:CreateRole and iam:AttachRolePolicy, conditioned on the boundary being attached
3. Deny iam:DeleteRolePermissionsBoundary and boundary modification

Teams create roles freely; the boundary caps them. Course 1 Module 02 Topic 7 covers the mechanism.

The condition is what makes it work - without iam:PermissionsBoundary in the condition, a team can create a role without a boundary and escape the constraint entirely. This is the most common implementation error.

Break-Glass

Every organisation needs an emergency path, and most designs are either unusable or unmonitored.

What it is for: the identity provider is down, Identity Center is unavailable, or a change has locked everyone out.

The design:

• A dedicated IAM role or user in the management account and in critical workload accounts - one of very few legitimate IAM user cases, because it must work when federation does not
• Credentials in physical or sealed storage, split so no single person holds complete access
• MFA with a hardware token, stored separately
• A CloudWatch alarm on any use, routed to a channel and to a person, not to a queue
• A documented procedure for what to do afterwards: rotate, review, and record

Tip: Test break-glass on a schedule, and treat an untested one as absent. The failure mode is uniform: credentials in a safe nobody can open, an MFA device with a dead battery, a procedure referencing a system that was decommissioned, or a role whose policy was tightened and now grants nothing useful.

A quarterly test that retrieves the credentials, authenticates, performs a trivial action, and rotates takes an hour and is the only thing that establishes the path works. Run it as a game day so the people who would need it have actually done it.

Machine Identity

No workload should hold a long-lived credential. Every context has a temporary-credential mechanism.

ExternalId matters for third parties specifically. Without it, a vendor holding many customers' role ARNs can be tricked into assuming yours - the confused deputy problem. Course 1 Module 02 Topic 4.

Tip: Make "zero IAM users with access keys" a measured target rather than an aspiration.

The query is straightforward: list IAM users across every account, filter to those with active access keys, and record the last-used date. Publish the number monthly and drive it down. Each key falls into one of four cases - a human who should use Identity Center, a workload that should use a role, a CI system that should use OIDC, or an on-premises application that should use Roles Anywhere. All four have a defined path.

The residual is usually break-glass and a small number of genuinely stuck integrations. A number you track goes down; an aspiration does not.

Access Reviews And Privileged Access

Access reviews - periodic confirmation that people still need what they have - are a compliance requirement in most frameworks and useful regardless. With group-based assignment they are a review of group membership in your IdP, which is where the tooling already exists.

Privileged access to production deserves a specific decision:

• Who holds ProductionOperator or above, and is it the smallest set that works?
• Is production write access standing, or requested? Just-in-time elevation with an approval and a time limit is stronger than standing access.
• Is elevated use alarmed? Assumption of a privileged role in production should be visible.
• Can anyone bypass the pipeline? Module 04 Topic 1. If yes, the pipeline is a convention rather than a control.

Standing production write access for every engineer is the default in most organisations and it is worth challenging. The common counter - "we need it for incidents" - is answered by break-glass and by just-in-time elevation, both of which are auditable in a way standing access is not.

Common Failure Modes

Warning: No SCIM. Deprovisioning is manual and will be missed.

Permission sets assigned to individuals. Never reviewed, never removed.

Permission set proliferation. Sixty sets nobody can reason about.

ABAC over inconsistent tagging. Access failures that look like policy bugs.

Delegated role creation without the boundary condition. The constraint is escapable.

Break-glass untested. Discovered unusable during the incident.

Break-glass use not alarmed.

IAM users with access keys for workloads that have a role path.

No ExternalId on third-party roles.

Standing production write access for everyone, unchallenged.

No access review process.

Identity Center in a Region nobody thought about. It is a single-Region service with a delegated administration model - decide deliberately.

Why This Matters In An Interview

Interview: Identity architecture is a strong senior signal, because the failures are organisational and appear over time.

What interviewers are listening for:

• Federation with SCIM as the joiner-mover-leaver mechanism.
• A small permission set catalogue, with variation handled by ABAC or account scoping.
• Permission boundaries for safe delegation, and the condition that makes them enforceable.
• Zero long-lived credentials as a measured target.

Common follow-ups:

• "How do engineers get access to fifty AWS accounts?" → Identity Center federated from the corporate IdP with SCIM provisioning, a small permission set catalogue assigned to groups, scoped by account. Not a role per person per account.
• "A team needs to create IAM roles for their own workloads. How do you allow it safely?" → Permission boundaries. Grant iam:CreateRole conditioned on iam:PermissionsBoundary matching your boundary policy, and deny removing it. Without the condition, they can create a role without a boundary.
• "How do you eliminate long-lived access keys?" → Enumerate them, categorise into four cases - human, workload, CI, on-premises - and each has a path: Identity Center, roles, OIDC, Roles Anywhere. Measure the count monthly.
• "What is your break-glass procedure?" → A dedicated credential outside federation, split custody, hardware MFA, alarmed on use, and tested quarterly. Then the honest part: an untested break-glass is not a break-glass.

Practice

Exercise: Starter. Count IAM users with active access keys across the organisation, with last-used dates. Categorise each into one of the four cases.

Intermediate. Audit the permission set catalogue. Count sets, count holders per set, and identify sets used by fewer than three people - each is a candidate for consolidation or ABAC.

Advanced. Implement delegated role creation with a permission boundary, including the iam:PermissionsBoundary condition. Verify from a delegated principal that a role cannot be created without the boundary and cannot exceed it.

Related Topics

• Topic 1 - The accounts identity spans
• Topic 3 - Network access as the complementary control
• Module 05 Topic 1 - SCPs as the outer boundary
• Course 1 Module 02 Topics 4, 7, 9 - AssumeRole, permission boundaries, Identity Center
• Course 1 Module 09 Topic 12 - OIDC for CI

Back to DevOps and Platform Engineering on AWS