Cloud Sandbox
All notes

Human access and workload identity should not look alike

Humans and software may both receive temporary AWS credentials, but their identity journeys should remain visibly different. Workforce federation, interactive sessions and organisational groups solve different problems from workload trust, runtime roles and automatic credential delivery.

about 16 minutes min read

A platform engineer needs to inspect a production failure.

A GitHub Actions workflow needs to deploy a new application version.

A Kubernetes Pod needs to read objects from Amazon S3.

All three actors eventually make signed requests to AWS.

All three may receive temporary credentials for an IAM role.

That similarity can make their identity designs look deceptively interchangeable.

human
   │
   ▼
IAM role
   │
   ▼
AWS API


pipeline
   │
   ▼
IAM role
   │
   ▼
AWS API


Pod
   │
   ▼
IAM role
   │
   ▼
AWS API

The right side of the diagram looks the same.

The trust journey on the left should not.

A human should arrive through a workforce identity system built around named people, authentication, organisational membership, account assignments and interactive sessions.

A workload should arrive through machine identity built around runtime location, service accounts, repositories, workflows and automatic short-lived sessions.

AWS recommends temporary credentials for both. IAM Identity Center manages workforce access; IAM roles and federation mechanisms serve software.

Humans and workloads may use the same AWS authorisation machinery, but they should not use the same identity story.

Their trust conditions, session behaviour, permissions, lifecycle and audit evidence should make the difference obvious.

The identity represents a different thing

A human identity represents a person with an organisational relationship.

For bfstore, Mariam may act as a platform engineer, security operator or production investigator.

The workforce identity system should know that Mariam is the person holding those responsibilities.

MARIAM
   │
   ▼
WORKFORCE DIRECTORY
   │
   ▼
ORGANISATIONAL GROUP
   │
   ▼
AWS ACCOUNT ASSIGNMENT
   │
   ▼
TEMPORARY HUMAN SESSION

IAM Identity Center connects workforce users to AWS accounts. Permission sets define access profiles; account assignments connect people or groups to accounts.

A workload identity represents software performing a function.

Examples include catalog-service, a backup controller, a deployment workflow or an EKS add-on.

A workload does not join the organisation through a hiring process.

Its identity comes from the environment in which it executes.

CATALOG POD
    │
    ▼
KUBERNETES SERVICE ACCOUNT
    │
    ▼
WORKLOAD IDENTITY MECHANISM
    │
    ▼
CATALOG IAM ROLE
    │
    ▼
TEMPORARY WORKLOAD CREDENTIALS

The person belongs to the organisation. The workload runs in an approved technical context.

The point of trust is different

A human and a workload may both assume IAM roles.

What convinces AWS to issue the session should be different.

For a human, AWS should be able to ask:

Was this person authenticated,
and does their organisational responsibility
grant this access profile?

For a workload:

Did the request come from the approved issuer,
and do its runtime or workflow claims
satisfy the role trust policy?

HUMAN TRUST

person
directory
MFA
group membership
account assignment


WORKLOAD TRUST

issuer or service principal
repository or runtime
service account
namespace
workflow context

The role is common machinery.

The evidence used to enter it should match the actor.

Interactive and automatic access behave differently

Human access is usually interactive.

The engineer authenticates, selects an account and access profile, performs a task and lets the session expire.

Workload access should be automatic. The application starts in its approved runtime, discovers its credential provider, receives and refreshes credentials, and performs its service function.

Credentials already issued may remain effective until they expire unless the incident process explicitly denies or revokes the active role sessions.

There should be no engineer copying credentials into a Kubernetes Secret, CI variable, .env file or container image.

HUMAN

authenticate
choose responsibility
perform task
session expires


WORKLOAD

start
obtain credentials automatically
perform service function
refresh credentials
stop

Temporary credentials reduce reliance on stored secrets.

They do not make human and machine sessions operationally identical.

Permission sets should not become application roles

IAM Identity Center creates IAM roles from permission sets in assigned AWS accounts. Their names commonly begin with:

AWSReservedSSO_

Those roles exist to provide workforce access through the AWS access portal or CLI. Permission sets are not an application identity mechanism.

A human permission set might be:

permission_set:
  name: ProductionInvestigator
  purpose: investigate production incidents

permissions:
  - inspect workloads
  - read deployment status
  - query selected logs
  - view service configuration

session_duration: 2h

A workload role might be:

role:
  name: catalog-assets-reader
  purpose: allow catalog-service to read product assets

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

permissions:
  - action: s3:GetObject
    resource: product-assets/catalog/*

Application trust should not depend directly on a generated AWSReservedSSO_ role ARN. If all assignments are removed, IAM Identity Center can delete the role; a later assignment creates a different unique suffix and can break policies that reference the old ARN.

The human access profile is tied to organisational responsibility. The workload role is tied to software execution.

Humans should not lend their identity to automation

A deployment script run from an engineer’s laptop may initially use that engineer’s Identity Center session.

For a development experiment, this can be understandable.

It should not become the production delivery model.

MARIAM'S SESSION
       │
       ▼
DEPLOYMENT SCRIPT
       │
       ▼
PRODUCTION CHANGE

The deployment then depends on one person’s access, session lifetime and ability to authenticate. The audit trail may identify the human session without clearly identifying the delivery workflow.

Production automation should present its own identity.

APPROVED REPOSITORY
       │
       ▼
PROTECTED WORKFLOW
       │
       ▼
OIDC TOKEN
       │
       ▼
PRODUCTION DEPLOYMENT ROLE

For GitHub Actions, the AWS trust policy should validate the token audience and narrowly match the subject to the approved repository and branch, tag or environment.

GitHub enforces environment reviewers and branch protections. AWS evaluates the resulting token claim.

The person may approve or trigger the workflow.

The workflow performs the AWS action through its own role.

Publication chronology: When this article was published on 10 March 2026, GitHub’s default OIDC subject used mutable owner and repository names. Repositories created after 15 July 2026, or repositories that opt in, can use an immutable subject containing owner and repository IDs. Trust policies must match the subject format used by the repository.

EKS Pod Identity and IRSA are different workload paths

EKS Pod Identity and IAM roles for service accounts both give Pods temporary AWS credentials.

Their trust paths are different.

Mechanism Trust path Credential delivery
EKS Pod Identity An EKS association maps a cluster, namespace and service account to a role that trusts pods.eks.amazonaws.com The EKS Auth service assumes the role, adds session tags and the Pod Identity Agent supplies credentials through the SDK chain
IRSA The role trusts the cluster’s IAM OIDC provider and evaluates projected service-account token claims The SDK exchanges the token through AssumeRoleWithWebIdentity

For new bfstore workloads, Pod Identity is the preferred default where its compatibility and account model fit. IRSA remains useful where its OIDC trust model, tooling or cross-account pattern fits better.

Neither mechanism turns the Kubernetes service account into a human user.

Both should map the workload’s execution context to narrow AWS authority.

Workloads should not inherit human convenience

Human access often needs investigative breadth across workloads, logs, configuration, deployments and alarms.

A runtime service usually needs a much smaller set of actions.

The catalog service may only need:

Read objects from one product-assets prefix.

The order service may need:

Write objects to one protected order archive.

Giving both services a broad platform-engineer role because it already exists would convert human convenience into runtime privilege.

HUMAN ROLE

broad enough to investigate
several connected systems


WORKLOAD ROLE

narrow enough to perform
one service function

A human may need to understand the surrounding estate.

A workload should not explore it.

Identity purposes and trust paths must remain separate.

That does not require one role per Pod. Pod Identity session tags and association policies can support controlled reuse when ownership, attribution and isolation remain clear.

Human and workload lifecycles are different

A human identity changes when the person joins, moves teams, receives temporary duties or leaves. The response may change group membership, account assignments, session duration or active sessions.

Removing an assignment or disabling a user prevents new AWS role sessions. Existing role sessions can continue until their configured expiry, potentially for several hours, unless an explicit revocation or deny process is used.

A workload identity changes when a service is created, moved, renamed, given a new dependency or retired. The response may change its IAM role, trust policy, Pod Identity association, OIDC conditions or resource-policy grants.

Deleting a Pod Identity association prevents future credential delivery, but credentials from the previous role session may remain valid until expiry unless they are explicitly revoked.

HUMAN

join
move
temporary elevation
leave


WORKLOAD

deploy
change dependency
move runtime
retire

Both lifecycles should be automated, not represented through the same directory object.

catalog-service is not an employee who forgot to submit its onboarding forms.

Sensitive human access may be temporary

Ordinary workforce access can come from long-lived group membership and account assignments.

Sensitive production authority may deserve a separate path.

BASELINE HUMAN ACCESS

group membership
    │
    ▼
ordinary permission set


TEMPORARY ELEVATED ACCESS

request
    │
    ▼
approval
    │
    ▼
time-bounded assignment
    │
    ▼
recorded use

Temporary elevated access, also called just-in-time access, lets a person request, receive approval for and use sensitive authority for a defined task and period.

A person requests responsibility temporarily. A workload receives authority automatically from its approved execution context.

Just-in-time access handles controlled elevation. Break-glass access handles failure of the normal workforce path.

Audit evidence should preserve the original actor

Humans and workloads may both appear in CloudTrail as assumed-role sessions, so the investigation must preserve enough context to tell them apart.

Actor Evidence to preserve
IAM Identity Center user userIdentity.onBehalfOf.userId, identityStoreArn, permission set, account and session
GitHub workflow repository, subject claim, branch, tag or environment, workflow run, commit and role session
EKS Pod Identity cluster ARN and name, namespace, service account, Pod name, Pod UID and IAM role
IRSA workload OIDC issuer, subject claim, namespace, service account and assumed-role session

EKS Pod Identity can attach session tags including:

eks-cluster-arn
eks-cluster-name
kubernetes-namespace
kubernetes-service-account
kubernetes-pod-name
kubernetes-pod-uid

Where a federation mechanism supports sourceIdentity, preserving it can help retain actor context through later role assumptions.

ORIGINAL ACTOR
      │
      ▼
TRUST CONTEXT
      │
      ▼
ROLE SESSION
      │
      ▼
AWS API EVENT

A log entry that says only:

Role:
    PlatformAdministrator

is incomplete when both people and software can use the role.

A stronger design can attribute the event to Mariam using ProductionInvestigator, or to the production workflow deploying commit 4f72a9c.

The audit trail should preserve the actor’s nature rather than sanding every session into the same anonymous role shape.

Break-glass access is still human access

A break-glass path exists for exceptional human recovery when normal workforce federation is unavailable or broken.

It may be needed when the external identity provider is unavailable, assignments are broken or federation configuration fails.

The emergency identity should be protected, individually attributable, monitored, tested and reviewed after use.

NORMAL HUMAN ACCESS

workforce IdP
    │
    ▼
IAM Identity Center
    │
    ▼
temporary account session


EMERGENCY HUMAN ACCESS

protected recovery identity
    │
    ▼
narrow recovery authority

It is still a person exercising judgement.

It should not become a credential stored in automation merely because it bypasses the normal human path.

Shared roles create confused ownership

Consider a role named:

bfstore-platform-role

It can be assumed by:

  • Platform Engineers;
  • GitHub Actions;
  • TerraKube;
  • EKS controllers;
  • an emergency administrator.

The policy grows to support deployment, infrastructure, logs, IAM, networking and databases.

MANY ACTORS
     │
     ▼
ONE PLATFORM ROLE
     │
     ▼
BROAD AUTHORITY

The role becomes difficult to review. Changes may break unknown actors, compromise has a large blast radius, and CloudTrail no longer clarifies ownership.

The stronger design is:

Platform Engineer
    └── PlatformOperator


GitHub Actions
    └── ProductionDeployer


TerraKube
    └── InfrastructureReconciler


EKS controller
    └── ControllerSpecificRole


Emergency operator
    └── BreakGlassRecovery

The roles may overlap in permissions, but their trust, purpose and lifecycle remain separate. A little policy duplication is cheaper than one identity whose meaning has dissolved.

The bfstore boundary

For bfstore, the identity split should be visible in the architecture.

WORKFORCE PLANE

Mariam
  │
  ▼
identity provider
  │
  ▼
IAM Identity Center
  │
  ▼
groups, permission sets
and account assignments
  │
  ▼
interactive AWS sessions


DELIVERY PLANE

GitHub Actions / TerraKube
  │
  ▼
OIDC or dedicated workload trust
  │
  ▼
environment-specific IAM roles
  │
  ▼
automated AWS sessions


RUNTIME PLANE

EKS workload
  │
  ▼
Kubernetes service account
  │
  ▼
Pod Identity or IRSA
  │
  ▼
service-specific AWS authority

The boundaries are reinforced through naming.

Human permission sets might use:

PlatformDeveloper
ProductionInvestigator
SecurityOperator
NetworkOperator

Delivery roles might use:

bfstore-dev-deployer
bfstore-prod-deployer
network-infrastructure-reconciler

Runtime roles might use:

catalog-assets-reader
order-archive-writer
external-dns-controller

The names should reveal who or what uses the identity, which trust path creates the session, who owns its permissions and how it is retired.

The questions I keep

Before writing a policy, I ask:

Is the actor a person or software?

Does it enter through workforce federation
or workload trust?

Is the session interactive or automatic?

Does its lifecycle follow a person
or an application?

Will the session preserve
the original actor's context?

The mental model I am keeping

My earlier model was:

IDENTITY
   │
   ▼
IAM ROLE
   │
   ▼
TEMPORARY CREDENTIALS

The stronger model is:

                           ACTOR
                             │
              ┌──────────────┴──────────────┐
              │                             │
              ▼                             ▼
            HUMAN                        WORKLOAD
              │                             │
              ▼                             ▼
     WORKFORCE AUTHENTICATION        MACHINE AUTHENTICATION
              │                             │
              ▼                             ▼
      ORGANISATIONAL GROUP          RUNTIME OR WORKFLOW CLAIMS
              │                             │
              ▼                             ▼
     ACCOUNT ASSIGNMENT              ROLE TRUST POLICY
              │                             │
              ▼                             ▼
    HUMAN ACCESS PROFILE            WORKLOAD AUTHORITY
              │                             │
              └──────────────┬──────────────┘
                             ▼
                  TEMPORARY AWS CREDENTIALS
                             │
                             ▼
                     AUTHORISED REQUEST

Workforce identity answers:

Which person is acting,
and which organisational
responsibility do they hold?

Workload identity answers:

Which software is running,
and which technical context
makes its claim trustworthy?

Permission sets and workload roles answer:

Which access profile or service capability
does this actor require?

Lifecycle and audit controls answer:

How does authority end,
and can we still identify
the original actor?

Humans and workloads both need temporary credentials, narrow permissions and useful evidence.

That is where the resemblance should end.

A human identity represents organisational responsibility. A workload identity represents software executing within an approved technical context.

Making them look alike weakens both. The human path loses accountability; the workload path inherits interactive assumptions and broad permissions.

A mature identity architecture lets both actors reach AWS without pretending they arrived for the same reason.

The engineer walks through the workforce entrance.

The deployment workflow uses the delivery hatch.

The Pod receives the key to one carefully labelled cupboard.

They all enter the same building.

They do not need matching visitor badges.

References and further reading