IAM Identity Center is the workforce layer, not the whole identity system

A platform engineer signs in to AWS.

A GitHub Actions workflow deploys infrastructure.

A Kubernetes Pod reads an object from Amazon S3.

A customer signs in to the bfstore application.

All four need identity.

That does not make them the same kind of identity.

HUMAN ENGINEER

interactive workforce user
changes responsibilities
may require MFA
works across accounts


DELIVERY WORKFLOW

non-human automation
runs for one repository and job
should receive short-lived deployment authority


APPLICATION POD

runtime workload
acts continuously for one service
should receive service-specific authority


CUSTOMER

application user
accesses bfstore capabilities
should not receive AWS administration access

A weak design flattens these distinctions.

It creates IAM users for engineers.

It stores AWS keys in CI secrets.

It lets every Pod inherit the node role.

It treats customer authentication as another form of cloud-console access.

The identities technically exist.

Their trust, ownership, lifecycle and evidence are muddled.

Identity architecture begins by recognising the actor before choosing the authentication mechanism.

For bfstore, IAM Identity Center is the workforce layer.

It is not the whole identity system.

Four identity planes

The architecture starts with four planes.

                         IDENTITY ARCHITECTURE
                                  │
          ┌───────────────────────┼───────────────────────┐
          │                       │                       │
          ▼                       ▼                       ▼
      WORKFORCE                DELIVERY               RUNTIME
          │                       │                       │
          ▼                       ▼                       ▼
 IAM Identity Center        OIDC federation        service identity
          │                       │                       │
          └───────────────────────┼───────────────────────┘
                                  │
                         AWS IAM AUTHORITY


                         CUSTOMER IDENTITY
                                  │
                                  ▼
                       APPLICATION AUTHORITY

Plane	Actor	Authority system	Typical trust source
Workforce	Employees and operators	AWS account roles	Workforce identity provider
Delivery	CI/CD and platform automation	Deployment roles	Repository and workflow claims
Runtime	Applications and AWS services	Workload roles	Runtime or AWS service identity
Customer	Application users	Domain permissions	Customer identity provider

Workforce, delivery and runtime actors may receive temporary AWS authority.

Customers remain inside the application authorization system.

The planes meet at controlled interfaces.

They do not become one universal identity directory.

Give every identity an operating contract

The implementation differs by plane.

The architectural questions remain stable.

ACTOR

TRUST ISSUER

ASSUMPTION CONDITIONS

SESSION

AUTHORITY

LIFECYCLE

EVIDENCE

A delivery identity may be described as:

identity:
  name: catalog-production-deployer
  type: delivery
  owner: catalog-platform

actor:
  authority_source: GitHub Actions
  identifier: bfstore/catalog
  environment: production

trust:
  issuer: token.actions.githubusercontent.com
  audience: sts.amazonaws.com
  accepted_subject: repo:bfstore/catalog:environment:production

session:
  maximum_duration: 1h
  credentials: temporary
  source_identity: deployment-run-id

targets:
  accounts:
    - bfstore-prod

permissions:
  purpose: deploy catalog workload
  prohibited:
    - assume runtime role
    - change organisation policy
    - read customer data

lifecycle:
  created_by: platform-automation
  reviewed: quarterly
  revoked_when:
    - repository retired
    - production environment removed
    - deployment path replaced

evidence:
  - OIDC claims
  - workflow run
  - role session
  - CloudTrail events

The same contract shape works for a human assignment or Kubernetes workload.

It prevents the role policy from becoming the entire identity design.

IAM Identity Center is for the workforce

AWS IAM Identity Center connects workforce users to AWS accounts and applications.

For multi-account access, bfstore needs an organization instance of IAM Identity Center.

BFSTORE REQUIREMENT

organization instance
of IAM Identity Center

WHY

permission sets
account assignments
multi-account access

NOT SUFFICIENT

account instance

An organization instance supports permission sets and AWS account assignments across the organisation.

An account instance is bound to one AWS account and does not support AWS account access through permission sets.

The organization instance resides in the AWS Organizations management account.

Routine administration can be delegated to a protected member account, but the instance remains associated with the management account.

The human access path is:

MARIAM
   │
   ▼
WORKFORCE IDENTITY SOURCE
   │
   ▼
IAM IDENTITY CENTER
   │
   ▼
ACCOUNT ASSIGNMENT
   │
   ▼
PERMISSION SET
   │
   ▼
ACCOUNT-LOCAL IAM ROLE
   │
   ▼
TEMPORARY SESSION

IAM Identity Center does not create a permanent IAM user for Mariam in every account.

It brokers access to IAM roles generated from centrally managed permission sets.

The identity source establishes the person

IAM Identity Center needs an authoritative identity source.

Options include:

the IAM Identity Center directory
Microsoft Active Directory
an external identity provider

With an external provider, two mechanisms solve different problems.

SAML

carries the sign-in assertion

SCIM

provisions users, groups
and membership information

SAML answers:

Has the identity provider
authenticated this person?

SCIM helps answer:

Which workforce users and groups
should IAM Identity Center know now?

The source directory should remain authoritative for the human lifecycle.

IAM Identity Center should not become a shadow personnel database that quietly disagrees with it.

Where an external source is authoritative, write operations against the Identity Store should be restricted. Local changes may be overwritten by synchronisation, and administrators able to alter group membership or create SCIM bearer tokens can indirectly change AWS access.

Authentication and provisioning need separate monitoring:

federation configuration
signing certificates
MFA policy
SCIM synchronisation
failed provisioning
disabled users
group changes
identity-provider availability

Federation centralises the decision.

It does not make the decision disappear.

MFA responsibility follows the identity source

When the IAM Identity Center directory or a supported Active Directory arrangement is used, Identity Center can participate in MFA configuration.

When an external identity provider performs authentication, the external provider owns MFA enforcement for that sign-in path.

The operating model should record:

Authentication owner

MFA requirement

MFA administrator

sign-in evidence

recovery procedure

IAM Identity Center trusts the assertion it receives.

The organisation must decide which authentication conditions make that assertion strong enough for AWS access.

Translate responsibility into AWS access

Human access has four connected parts.

WORKFORCE USER
      │
      ▼
RESPONSIBILITY GROUP
      │
      ▼
ACCOUNT ASSIGNMENT
      │
      ▼
PERMISSION SET

Groups represent stable responsibility

Useful bfstore groups include:

BFStore-Platform-Engineers

BFStore-Security-Operators

BFStore-Network-Operators

BFStore-Application-Developers

BFStore-Production-Investigators

BFStore-Billing-Viewers

The group answers:

Which organisational responsibility
does this person currently hold?

It should not mirror individual IAM statements.

The same group may receive different permission sets in different accounts.

Being a Platform Engineer does not require identical authority everywhere.

Permission sets are workforce access templates

A permission set defines the account access profile provided to a user or group.

It may contain:

AWS-managed policies
customer-managed policy references
inline policy content
a permissions boundary
session settings

permission_set:
  name: ProductionInvestigator
  purpose: diagnose production incidents without changing workloads

session:
  duration: 2h

permissions:
  allow:
    - read service configuration
    - query operational telemetry
    - inspect deployment status
    - read selected logs

  not_granted:
    - deploy application
    - change IAM
    - delete resources
    - modify network configuration

Permission sets are part of the workforce access product.

Workload roles belong to workload identity.

Assignments join actor, authority and boundary

An account assignment joins:

a user or group
an AWS account
a permission set

BFStore-Platform-Engineers
            │
            ▼
      bfstore-staging
            │
            ▼
      PlatformDeployer

Changing any element changes access.

A group membership change affects the people.

A permission-set change affects every assignment using it.

An account assignment changes where the authority can be exercised.

Identity Center creates account-local roles

When a permission set is assigned to an account, IAM Identity Center creates a corresponding role there, commonly with a name beginning:

AWSReservedSSO_

The permission set is the central template.

The role is the account-local enforcement identity.

IAM Identity Center does not replace IAM.

It orchestrates IAM roles for workforce access.

Treat management-account access differently

The management account owns the organisation and is not constrained by SCPs.

Its Identity Center access should not follow the ordinary member-account assignment model.

MEMBER ACCOUNTS

group-based responsibility assignments


MANAGEMENT ACCOUNT

direct named-user assignments
dedicated permission sets
very small population

AWS recommends assigning users directly, rather than groups, to permission sets granting management-account access. A group administrator in the identity provider could otherwise change group membership and indirectly grant constitutional authority.

Where a group is retained exceptionally, membership changes need unusually strong controls, logging and review.

Permission sets provisioned to the management account also have additional administration restrictions. A delegated Identity Center administrator cannot modify them from the delegated member account.

A bfstore model might include:

OrganisationViewer

BillingReadOnly

TemporaryOrganisationAdministrator

The broadest profile should have:

direct named-user assignment
strong authentication
short duration
explicit activation
monitored use
no daily engineering purpose

The identity platform should help keep the management account boring.

Sessions, offboarding and revocation

“Signed out” is not one state.

IAM Identity Center has several session layers.

EXTERNAL IdP SESSION
        │
        ▼
IDENTITY CENTER INTERACTIVE SESSION
        │
        ├── application session
        │
        └── AWS ACCOUNT ROLE SESSION
                 │
                 └── continues independently
                     until role-session expiry

The access-portal interactive session can be configured separately from AWS account role sessions.

Permission-set role sessions normally last from one to twelve hours.

The interactive session may last longer, according to Identity Center and identity-source settings.

Ending the portal session stops creation of new sessions.

It does not immediately terminate an already issued AWS console or CLI role session.

Removing a group assignment or disabling a user also leaves existing role sessions active until their configured expiry unless an emergency revocation control is used.

Normal offboarding

disable source identity

remove responsibility groups

remove direct assignments

prevent new sessions

allow deliberately short
role sessions to expire

review recent activity

Emergency revocation

A compromised identity requires a stronger process.

prevent new sessions

end the interactive session

apply the prepared user-specific
deny mechanism

remove assignments and groups

disable the source identity

retain the deny until
existing role sessions expire

verify blocked activity

AWS documents an emergency method using an SCP deny tied to the Identity Store user ID. This requires preparation before an incident and should be automated as far as practical.

Session duration is therefore part of incident containment.

A twelve-hour role session may remain valid for twelve hours after ordinary access is removed.

Break-glass is a separate identity path

Federated access can fail because of:

external IdP outage
SAML failure
SCIM drift
accidental assignment loss
Identity Center disruption

A recovery path may need an independently protected credential.

NORMAL ACCESS

IdP
  │
  ▼
IAM Identity Center
  │
  ▼
temporary account role


EMERGENCY ACCESS

protected independent identity
  │
  ▼
narrow recovery authority
  │
  ▼
restore the normal system

Break-glass access should have:

narrow purpose
strong credential protection
multi-person control where practical
very short use
immediate alerting
complete logging
periodic testing
post-use review

It exists to recover the identity system.

It should not become the fastest route around it.

Delivery identity is not workforce access

A GitHub Actions workflow may need to publish an artefact or deploy infrastructure.

It should not borrow Mariam’s permission set or use a long-lived IAM access key.

GITHUB ACTIONS
      │
      ▼
OIDC TOKEN
      │
      ▼
ROLE TRUST POLICY
      │
      ▼
TEMPORARY DEPLOYMENT SESSION

The trust should constrain:

audience
organisation
repository
branch or environment
deployment context

For a protected production environment:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub":
        "repo:bfstore/catalog:environment:production"
    }
  }
}

AWS requires a GitHub sub condition that is not only a wildcard when the trust policy is created or updated.

GitHub environments should also use protection rules.

Repository ownership is not enough.

The trust should identify the exact deployment context that may become the role.

Development and production should use separate roles and conditions.

The workflow presents its own machine identity.

Runtime identities belong to services

A runtime workload does not need:

a human password
an access-portal tile
a workforce group
a permission set designed for engineers

It needs workload-specific trust and narrow authority.

WORKLOAD
    │
    ▼
RUNTIME TRUST
    │
    ▼
IAM ROLE
    │
    ▼
TEMPORARY CREDENTIALS

The identity should follow the service boundary.

catalog-service
      │
      ▼
catalog-assets-reader


order-service
      │
      ▼
order-archive-writer

A microservice architecture with one shared cloud identity has separated code while quietly recombining authority.

AWS services use service trust

Lambda execution roles, EC2 instance profiles, ECS task roles and service-linked roles are assumed through AWS service relationships.

A human may administer those roles through workforce access.

The AWS service uses them through service trust.

Administration and execution are different identity paths.

EKS workloads need service-specific AWS roles

A Pod may need to access S3, KMS, Route 53 or another AWS service.

The weak pattern gives every Pod the node role.

MANY PODS
    │
    ▼
ONE NODE ROLE
    │
    ▼
SHARED AWS AUTHORITY

Amazon EKS supports:

EKS Pod Identity
IAM Roles for Service Accounts, or IRSA

Both associate a Kubernetes service account with temporary AWS authority.

KUBERNETES SERVICE ACCOUNT
          │
          ▼
WORKLOAD ROLE
          │
          ▼
TEMPORARY CREDENTIALS

EKS Pod Identity

A Pod Identity association selects:

cluster
namespace
Kubernetes service account
IAM role

The role trust uses:

pods.eks.amazonaws.com

and permits:

sts:AssumeRole
sts:TagSession

Pod Identity adds session tags carrying workload context such as cluster, namespace and service account. Those tags may be used in trust, permissions and audit design.

The association and trust perform different jobs:

EKS ASSOCIATION

selects cluster,
namespace and service account

ROLE TRUST

accepts the EKS Pod Identity service
and applicable conditions

SESSION TAGS

carry workload context
into authorization and evidence

One service account in a cluster can be associated with one role from the same AWS account as the cluster.

Cross-account access needs an additional target role and explicit trust.

IRSA

IRSA uses the EKS cluster’s OIDC issuer.

A projected Kubernetes service-account token is exchanged through STS.

The role trust directly constrains the issuer and token claims for the namespace and service account.

POD
 │
 ▼
SERVICE-ACCOUNT TOKEN
 │
 ▼
CLUSTER OIDC ISSUER
 │
 ▼
ROLE TRUST
 │
 ▼
TEMPORARY CREDENTIALS

Pod Identity and IRSA are implementation choices.

The stable requirement is:

Each workload receives narrowly scoped temporary authority based on its own runtime identity.

Pod identity does not remove node-role exposure automatically

Credential isolation also requires control of the EC2 Instance Metadata Service.

If IMDS access is not restricted, a Pod may still reach node-role credentials. Pods using hostNetwork: true retain IMDS access, although supported AWS SDKs prefer configured Pod Identity or IRSA credentials.

WORKLOAD IDENTITY

service-specific role

NODE CREDENTIAL ISOLATION

restrict IMDS access

CROSS-ACCOUNT ACCESS

explicit second role and trust

Creating a Pod Identity association alone does not make the node role irrelevant.

Customer identity stays inside the application

A bfstore customer may register, order products and review purchases.

The customer is a human.

They are not a member of the AWS workforce.

They should not receive:

an Identity Center account assignment
an AWS console role
an access-portal tile
a platform permission set

CUSTOMER
    │
    ▼
BFSTORE CUSTOMER IDENTITY
    │
    ▼
APPLICATION SESSION
    │
    ▼
DOMAIN AUTHORIZATION

The application workload then accesses AWS resources.

CUSTOMER REQUEST
      │
      ▼
ORDER SERVICE
      │
      ▼
ORDER-SERVICE ROLE
      │
      ▼
AWS RESOURCE

The customer does not inherit the workload role.

The workload does not become the customer in IAM.

Application evidence should retain the customer subject separately from the cloud execution identity.

AWS documentation also uses the phrase customer managed application for applications integrated with IAM Identity Center. That means the company manages the application. It does not mean Identity Center is the right identity store for the application’s customers.

Operate four different lifecycles

Plane	Creation	Change	Revocation
Workforce	Join organisation	Change responsibility	Disable source identity and assignments
Delivery	Register repository or workflow	Change branch or environment trust	Remove OIDC trust and deployment role
Runtime	Deploy service	Change namespace or dependency	Remove association and role trust
Customer	Register account	Change domain entitlements	Disable application identity and sessions

Every plane should answer:

Who owns the source identity?

What creates the access path?

Which event removes it?

How quickly must issued authority stop?

Which evidence proves removal?

Temporary credentials improve credential lifecycle.

They do not repair weak trust, excessive permission or incomplete deprovisioning.

Human access needs assurance levels

Not all workforce sessions deserve the same operating model.

DEVELOPMENT ACCESS

ordinary workforce authentication
responsibility group
working session
account-local authority


PRODUCTION INVESTIGATION

strong MFA
approved responsibility
short session
read-focused permission


PRODUCTION CHANGE

approved delivery workflow
rather than routine interactive mutation


EMERGENCY ADMINISTRATION

explicit activation
multi-person approval
very short session
immediate alert
post-use review

Session duration is not a substitute for least privilege.

A short administrator session is still an administrator session.

The assurance level combines:

authentication strength
assignment path
permission set
session duration
activation method
evidence
review

Identity design is evidence design

An AWS API event may show an assumed role rather than the original actor in plain English.

The platform needs correlation.

Plane	Useful correlation
Workforce	Identity Store user ID, permission set, role session, account, CloudTrail event
Delivery	Repository, workflow run, environment, session name, CloudTrail event
Runtime	Cluster, namespace, service account, Pod or deployment, IAM role, CloudTrail event
Customer	Customer subject, application session, trace ID, workload identity, API event

For supported applications and AWS services, trusted identity propagation and identity-enhanced role sessions can carry an IAM Identity Center user identifier into downstream authorization or audit context.

Support varies.

The design should still remain useful where a service records only the assumed role and session details.

ORIGINAL ACTOR
      │
      ▼
WORKFLOW OR APPLICATION CONTEXT
      │
      ▼
ASSUMED IAM ROLE
      │
      ▼
AWS API EVENT

Identity design is also evidence design.

Four bfstore identity contracts

Workforce

identity:
  name: ProductionInvestigator
  type: workforce

trust:
  source: corporate-idp
  group: BFStore-Production-Investigators
  mfa: required

authority:
  account: bfstore-prod
  permission_set: ProductionInvestigator
  session: 2h

lifecycle:
  remove_when: production responsibility ends

evidence:
  - identity-store-user-id
  - permission-set-session
  - cloudtrail

Delivery

identity:
  name: catalog-production-deployer
  type: delivery

trust:
  issuer: GitHub
  repository: bfstore/catalog
  environment: production

authority:
  account: bfstore-prod
  role: catalog-production-deployer
  session: 1h

lifecycle:
  remove_when: deployment path is retired

Runtime

identity:
  name: catalog-assets-reader
  type: runtime

trust:
  cluster: bfstore-prod
  namespace: catalog
  service_account: catalog-service

authority:
  actions:
    - s3:GetObject
  resources:
    - approved product-assets prefix

lifecycle:
  remove_when: service or dependency is retired

Customer

identity:
  name: bfstore-customer
  type: customer

trust:
  source: customer-identity-provider

authority:
  system: bfstore-domain
  capabilities:
    - manage basket
    - place order
    - view own order history

aws_access:
  direct: false

evidence:
  - customer-subject
  - application-session
  - request-trace

These contracts use common questions without pretending the implementations are interchangeable.

Questions I now ask

Plane

Which identity plane
does this actor belong to?

Source

Which system is authoritative
for the identity?

Trust

Which claims or relationships
permit role assumption?

Authority

Which account, role and resources
may the session reach?

Lifetime

How long may interactive
and role sessions survive?

Removal

Which event removes the identity
and blocks active authority?

Separation

Can another actor imitate
or borrow this identity?

Evidence

Which records link the original actor
to the AWS action?

Recovery

Which tested path remains
when normal identity fails?

These questions make identity a designed trust system rather than a collection of credentials.

The mental model I am keeping

My earlier model was:

AWS IDENTITY

users
roles
policies

The stronger model is:

                              ACTOR
                                │
          ┌─────────────────────┼─────────────────────┐
          │                     │                     │
          ▼                     ▼                     ▼
      WORKFORCE              DELIVERY              RUNTIME
          │                     │                     │
          ▼                     ▼                     ▼
     workforce IdP         OIDC issuer          runtime identity
          │                     │                     │
          ▼                     ▼                     ▼
 IAM Identity Center     deployment role       workload role
          │                     │                     │
          └─────────────────────┼─────────────────────┘
                                ▼
                     TEMPORARY AWS AUTHORITY


                          CUSTOMER ACTOR
                                │
                                ▼
                    APPLICATION AUTHORIZATION

IAM Identity Center answers:

Which workforce users may enter
which AWS accounts with which
human access profiles?

The identity source answers:

Who may assert that
the person is authenticated?

OIDC federation answers:

Which delivery workflow may exchange
its claims for an AWS session?

Runtime identity answers:

Which service instance may obtain
the application's AWS authority?

Customer identity answers:

Which application capabilities
may this customer use?

Lifecycle answers:

How is the access path changed,
revoked and proven absent?

Evidence answers:

Which original actor used
the resulting authority?

IAM Identity Center is one important part of bfstore’s identity architecture.

It is not the whole architecture.

Humans need workforce federation, organisational responsibility and interactive sessions. Delivery automation needs claims tied to repositories and environments. Runtime workloads need service-specific trust and narrow roles. Customers need application identity, not AWS administration.

The identities may all participate in one business service.

They should arrive through different doors.

That separation makes trust easier to explain, permissions easier to narrow, access easier to remove and incidents easier to investigate.

One universal identity type would look simpler on the diagram.

It would merely hide several different security problems beneath one familiar icon.