A request reaches a cloud API:
DeleteDatabase
The platform cannot decide whether to perform it from the action alone.
It needs to know:
Who or what initiated the request?
How was that identity established?
Which security principal is acting now?
Which actions and resources does that authority permit?
Why was the caller allowed to obtain or use it?
Which conditions, resource policies or guardrails apply?
That complete decision belongs to Identity and Access Management, usually shortened to IAM.
I initially treated IAM as a permissions table:
Alice can read storage.
Bob can restart servers.
The application can access the database.
That model was not entirely wrong.
It was simply too compressed. It blended identity, authentication, active authority, trust, permissions and policy evaluation into one vague idea of “the thing with access”.
A better model begins with four questions:
Who are you? Which authority is acting? What may that authority do? Why is the platform willing to accept it?
Across cloud platforms, IAM connects a recognised principal to permitted actions on resources under defined conditions.
The exact terminology differs.
AWS commonly uses assumable roles and temporary role sessions. Azure and Google Cloud often describe roles as permission sets assigned to principals at a scope.
The underlying security problem remains the same:
RECOGNISED PRINCIPAL
│
▼
GRANTED AUTHORITY
│
▼
RESOURCE AND ACTION
│
▼
REQUEST CONTEXT
│
▼
ALLOW OR DENY
Identity, principal, role and session are different things
An identity represents a person, workload or system that can be recognised.
Examples include:
human engineer
CI workflow
Kubernetes workload
virtual machine
cloud service
external identity provider
another cloud account
Authentication establishes that identity according to some mechanism.
AUTHENTICATION
Who are you?
Authorisation answers a different question:
AUTHORISATION
What are you allowed to do?
A person can authenticate successfully and still be denied access.
Mariam authenticated successfully.
Mariam is not authorised to delete
the production database.
A principal is the security actor evaluated for the request.
Depending on the platform, that principal might be:
a user
a service identity
a role session
a workload identity
a federated identity
an account
a cloud service
A role is a named description of authority, but the word does not mean exactly the same thing everywhere.
In AWS, a role is an IAM identity with permissions and a trust relationship. An approved principal can assume it and receive a temporary role session.
In other systems, a role may be a permission set assigned to a principal at a resource scope.
A session is a current instance of authority using active credentials.
Suppose an engineer signs in through a company identity provider and obtains a production read-only role session.
ORIGINAL IDENTITY
mariam@example.com
│
▼
FEDERATED LOGIN
│
▼
ACTIVE CLOUD PRINCIPAL
ProductionReadOnly / mariam@example.com
│
▼
CLOUD API REQUEST
The stronger statement is not:
Mariam has cloud access.
It is:
Mariam may establish a temporary session
for a defined authority,
and that session may perform
a limited set of actions.
Long-lived credentials should not be the default
A cloud platform may support locally created users, passwords and access keys.
That does not mean every human and workload should receive one.
For humans, a stronger model often uses an external identity provider:
COMPANY DIRECTORY
│
▼
IDENTITY PROVIDER
│
▼
CLOUD FEDERATION
│
▼
TEMPORARY CLOUD SESSION
For workloads, identity can be attached to the runtime:
virtual machine identity
container task identity
Kubernetes service-account federation
managed workload identity
CI OIDC federation
These models reduce dependence on permanent credentials stored in:
developer laptops
CI secret stores
container images
configuration files
shared password managers
The goal is not merely to hide access keys more carefully.
It is to avoid creating unnecessary long-lived credentials in the first place.
Temporary credentials provide:
an expiry time
a session identity
request context
bounded authority
an auditable lifecycle
They limit how long stolen credentials remain immediately useful.
They do not remove the need for least privilege, secure handling, revocation, careful trust and good audit records.
A fifteen-minute administrator session can still cause a spectacular fifteen minutes.
The AWS trust-and-role-session model
AWS roles answer two different questions.
WHO MAY OBTAIN A ROLE SESSION?
trust policy
WHAT MAY THE SESSION DO?
permissions policies
Suppose bfstore has a production deployment role:
BFStoreProductionDeploy
Its trust policy allows an approved deployment identity to request a role session.
Its permissions policies allow that session to update approved workloads and inspect rollout status.
DEPLOYMENT IDENTITY
│
│ trusted to assume
▼
PRODUCTION DEPLOY ROLE SESSION
│
│ permitted to perform
▼
APPROVED DEPLOYMENT ACTIONS
The trust policy points towards the caller.
Who may obtain this authority?
The permissions policies point towards actions and resources.
What may this authority do?
These questions must remain separate.
A permissions policy does not normally establish who may assume the role.
A trust policy does not automatically grant the resulting session useful access to every resource.
A principal that cannot assume a powerful role cannot normally exercise it directly. However, permission to pass, attach or modify that role may create another route to its authority.
Policies define effect, action, resource and context
A policy expresses rules about access.
A simplified permissions rule might say:
{
"effect": "allow",
"actions": [
"storage:GetObject"
],
"resources": [
"bfstore-artifacts/releases/*"
]
}
The rule contains several important dimensions:
EFFECT
allow or deny
ACTION
which operation
RESOURCE
which object or scope
CONDITION
under which circumstances
A policy is not merely:
read access
A useful review asks:
read which operation?
against which resource?
using which authority?
under which account, region,
network or token conditions?
for how long?
The more precisely these dimensions are expressed, the closer the policy approaches least privilege.
Identity-based and resource-based policy
An identity-based policy is associated with a user, group, role or similar security identity.
It says what that identity may do.
CATALOG RUNTIME AUTHORITY
│
├── read catalog configuration
├── connect to catalog data
└── publish catalog events
A resource-based policy is attached to a resource and identifies which principals may access it.
Examples can include policies on:
object-storage buckets
encryption keys
queues
topics
secret stores
service endpoints
The complete decision may involve both the caller’s grants and the resource owner’s policy.
Cross-account access is not granted merely because one side wrote Allow.
The acting principal and the resource owner must agree at the appropriate boundaries.
Permissions need scope and context
Role-based access control assigns permissions according to recognised responsibilities.
NetworkAdministrator
SecurityAuditor
DatabaseOperator
Attribute-based access control narrows decisions using properties.
principal team = platform
resource environment = dev
data classification = confidential
The approaches can work together:
ROLE
PlatformEngineer
CONDITION
may modify resources tagged:
project = bfstore
environment = dev
The role expresses the responsibility.
The attributes narrow where that authority applies.
This relies on trustworthy attributes. If anyone can rewrite a security-relevant tag, the tag is not a reliable boundary.
Wildcards deserve the same scrutiny.
storage:*
or:
resource:
*
may include future operations or resources that did not exist when the policy was written.
A wildcard is not always wrong. It may be appropriate for sandbox administration, tightly scoped resources, short-lived emergency access or services that cannot be narrowed further.
The review question is not merely:
Is there a wildcard?
It is:
Which dimension is broad?
Which other dimensions constrain it?
Who owns the exception?
When will it be reviewed?
An explicit deny can establish a protected boundary:
ALLOW
role may modify storage
DENY
protected backups may not be deleted
RESULT
protected backup deletion denied
Explicit denies and organisation guardrails need careful testing, ownership and break-glass design. A broad deny can block administrators, automation and recovery tooling while working exactly as written.
Effective access emerges from several policy layers
An Allow in one policy does not guarantee that a request succeeds.
The final decision may involve:
the authenticated principal
the active role or session
identity-based grants
resource-based policy
trust relationships
session restrictions
permission boundaries
organisation guardrails
service-specific policy
request conditions
explicit denies
A safer mental model is:
1. establish the principal and request context
2. identify applicable grants
3. evaluate resource-specific policy
4. apply boundaries and organisation controls
where relevant
5. reject the request if an applicable
explicit deny remains
The details differ by cloud and service.
The practical lesson is stable:
Debugging IAM requires checking the complete path rather than staring harder at one policy document.
A permissions boundary, for example, limits the maximum authority that identity-based policies can grant to an AWS IAM user or role.
It does not grant access by itself.
It does not establish trust.
It does not universally replace the evaluation of resource-based policy.
Organisation policies create another ceiling. They can prohibit actions across member accounts even when local IAM grants them.
Local IAM should still grant only the permissions needed within that ceiling.
Human access should be federated and role-based
Assigning policies directly to individual people creates a difficult lifecycle.
Mariam:
policy A
policy B
Alex:
policy A
policy C
Jo:
policy A
policy B
policy D
A stronger model maps people to job functions through central groups.
IDENTITY PROVIDER GROUP
│
▼
CLOUD PERMISSION SET
│
▼
ACCOUNT-SPECIFIC AUTHORITY
Groups might include:
PlatformEngineers
SecurityAuditors
DatabaseOperators
Developers
Joiner, mover and leaver processes become easier to reason about because human lifecycle remains in the central identity system.
Broad administration should be exceptional.
A stronger design separates:
daily working authority
from
administrator or break-glass authority
Administrative sessions may require:
strong authentication
multi-factor authentication
approval
short duration
named reason
enhanced logging
restricted source environment
Break-glass access should be protected, tested, monitored and reviewed after use.
Emergency access that has never been tested is partly a myth.
Workloads should receive runtime identity
A weak design places a permanent cloud access key inside a container image.
CONTAINER IMAGE
│
└── permanent access key
Every copy now carries the credential.
Rotation becomes a distribution problem.
Anyone who extracts the image may obtain it.
A stronger model attaches identity to the runtime workload.
CATALOG POD
│
▼
KUBERNETES SERVICE ACCOUNT
│
▼
FEDERATED CLOUD AUTHORITY
│
▼
READ CATALOG DATABASE SECRET
The workload receives temporary credentials associated with its runtime identity.
The image remains reusable and credential-free.
Different workloads should not share one universal application role.
CatalogRuntime
BasketRuntime
OrderRuntime
InventoryRuntime
NotificationRuntime
Each authority should reflect the responsibility of one service.
CATALOG RUNTIME
read catalog configuration
connect to catalog data
publish catalog-owned events
NOTIFICATION RUNTIME
consume approved order events
write notification jobs
call approved delivery provider
Service-specific identity improves policy review, incident response and audit.
The platform can answer:
Which workload made this request?
without every action appearing under one shared application authority.
The same principle applies to CI.
A deployment workflow can present an OIDC token and obtain a temporary role session without storing a permanent cloud key.
The combined CI-platform controls and cloud trust policy might require:
approved repository
protected environment
approved workflow identity
valid issuer, audience and expiry
The exact claims and subject format must be verified for the workflow design.
Trust and delegation create indirect privilege paths
Direct API permissions are not the only route to authority.
Suppose a developer cannot assume a production administrator role but can modify its trust policy.
They add themselves.
BEFORE
developer not trusted
CHANGE
developer edits role trust
AFTER
developer may obtain admin session
The permission to manage IAM is often equivalent to permission to create more permission.
Sensitive capabilities include:
create roles
attach policies
change trust
create access keys
modify identity providers
pass or attach roles to services
Passing a role is particularly important.
A caller may be unable to read production secrets directly but able to launch a workload with a powerful secret-administration role.
CALLER
cannot read secret directly
│
▼
creates workload with powerful role
│
▼
WORKLOAD READS SECRET
Role association should be limited to approved roles, services, environments and deployment paths.
Trusted cloud services can also become confused deputies.
A service identity alone may not prove that the service is acting for the intended customer resource.
Trust may need conditions for:
expected source account
expected source resource
expected organisation
expected external relationship
For third-party access, an external ID can help distinguish one customer relationship from another. It narrows trust; it does not replace minimal permissions, audit, revocation or periodic review.
Least privilege is a lifecycle
Least privilege means granting only the access required for an intended responsibility.
That sounds static:
find minimum policy
attach policy
finished
In practice, requirements change.
new feature
new dependency
new environment
incident workaround
retired operation
Least privilege is better treated as a continuing process:
grant narrowly
observe use
review denied requests
remove unused permissions
separate exceptional access
repeat
Temporary breadth should have:
an owner
an expiry
a reason
a review date
Otherwise temporary access becomes permanent architecture.
Usage evidence should inform reduction.
Which roles are still used?
Which permissions are exercised?
Which trust relationships remain necessary?
Which external identities may still obtain access?
The absence of recent use is not proof that a permission is unnecessary.
It is a reason to investigate.
IAM is one control in the complete access path
IAM does not answer every security question.
| Control | Question |
|---|---|
| IAM | May this principal perform the cloud action? |
| Network | Can the request reach the target? |
| Encryption-key policy | May this authority use the key? |
| Application authorisation | May this user perform the business operation? |
| Domain ownership | Should this component modify the data at all? |
A role may be authorised to call a service while the network makes it unreachable.
A storage policy may allow object access while the encryption key policy denies decryption.
A workload role may let the order service connect to its database while application authorisation still decides whether customer 72 may view order 5001.
IAM can technically permit analytics to write to the order database. The architecture may still be wrong if analytics does not own order state.
Cloud permissions should reinforce architectural authority rather than replace it.
A possible bfstore identity model
A possible bfstore design separates human, automation and workload identities.
Human identities
Humans authenticate through an external identity provider.
IDENTITY PROVIDER
│
▼
AWS IAM IDENTITY CENTER
│
▼
ACCOUNT-SPECIFIC ROLE SESSION
Groups might include:
BFStorePlatformEngineers
BFStoreSecurityAuditors
BFStoreDevelopers
BFStoreDatabaseOperators
Permission sets might include:
ReadOnly
Developer
PlatformOperator
SecurityAudit
EmergencyAdministrator
CI identities
GitHub Actions uses OIDC federation.
GITHUB WORKFLOW
│
▼
OIDC TOKEN
│
▼
CLOUD TRUST POLICY
│
▼
TEMPORARY CI ROLE SESSION
Separate authorities exist for planning, applying and deploying in different environments.
Production access is restricted through protected workflow and environment controls plus a precise cloud trust policy.
Kubernetes workloads
Each bfstore service uses a separate Kubernetes service account.
Where cloud API access is required, the service account is federated to a narrowly scoped cloud role.
CATALOG SERVICE ACCOUNT
│
▼
CATALOG RUNTIME ROLE
│
├── read catalog secret
└── write approved catalog storage
A workload that does not require cloud API access receives no cloud role.
Cross-account platform access
The observability account may ingest approved telemetry.
The backup account may copy protected recovery data.
The security account may inspect organisation-wide findings without receiving routine workload-administration rights.
Each relationship uses named trust and permission boundaries.
No account becomes an all-purpose administrative attic.
An IAM request walkthrough
Suppose the bfstore production deployment workflow updates the catalog workload.
1. The workflow authenticates externally
GitHub issues an OIDC token representing the workflow.
The combined GitHub environment controls and cloud trust policy establish the relevant repository, protected environment, workflow identity, issuer, audience and expiry.
2. The cloud evaluates trust
The production deployment role accepts only the approved external identity and context.
Is the issuer approved?
Is the audience correct?
Does the subject represent
the approved deployment context?
Is the token still valid?
3. A temporary role session is issued
role:
BFStoreProdApplicationDeploy
session:
workflow-run-84721
4. The workflow requests an action
Update catalog workload
to the approved release.
5. Permissions are evaluated
The role may update approved application workloads.
It may not:
modify IAM
delete the cluster
read unrelated secrets
change network policy
administer production databases
6. Other controls are evaluated
Resource policies, permission boundaries, organisation controls, service-specific policy, request conditions and explicit denies may still affect the result.
7. The action is audited
The audit record connects:
original workflow identity
role session
requested action
target resource
request context
result
This is much stronger than placing a permanent administrator key in the repository.
A compact IAM review
| Area | Review question |
|---|---|
| Identity | Who or what initiated the request? |
| Authentication | How was that identity established? |
| Active authority | Which principal, role or session is acting? |
| Trust | Why may the caller obtain or use that authority? |
| Permission | Which actions and resources are allowed? |
| Context | Which claims, tags, networks or conditions narrow the decision? |
| Delegation | Can the principal create, modify, pass or impersonate greater authority? |
| Guardrails | Which boundaries, organisation controls and explicit denies apply? |
| Audit | Can the action be traced to the original person or workload? |
| Lifecycle | When will the access expire, be reviewed or be removed? |
IAM design is not finished when an action succeeds.
It is finished when the reason it succeeds is narrow, understandable and auditable.
The mental model I am keeping
My earlier model was:
USER
│
▼
POLICY
│
▼
ACCESS
The stronger provider-neutral model is:
ORIGINAL IDENTITY
│
▼
AUTHENTICATION
│
▼
ACTIVE PRINCIPAL
│
▼
GRANTED AUTHORITY
│
┌────────────┴────────────┐
│ │
▼ ▼
REQUEST ACTION TARGET RESOURCE
│ │
└────────────┬────────────┘
▼
COMPLETE POLICY EVALUATION
│
┌──────────────────┴──────────────────┐
│ │
▼ ▼
ALLOW DENY
AWS often inserts an explicit trust and role-session transition:
original principal
to
trust evaluation
to
temporary role session
to
authorised request
A workload may follow a similar path:
runtime workload
to
federated identity
to
temporary credentials
to
authorised service action
The purpose of IAM is not to ensure that trusted people and applications can do everything they might eventually need.
It is to ensure that each request carries the smallest appropriate authority, obtained through a relationship we can explain.
A secure cloud system should be able to answer four questions without rummaging through a policy attic:
Who made this request?
Why were they allowed to use this authority?
What exactly did the authority permit?
Which control would have stopped the request from going further?
When those answers are clear, IAM stops looking like a wall of JSON and begins to look like an architecture of accountable trust.
References and further reading
AWS Identity and Access Management documentation Introduces AWS identities, roles, policies, temporary credentials and access evaluation.
AWS IAM roles Explains role trust policies, permissions policies and temporary role sessions.
AWS policy evaluation logic Describes how identity policies, resource policies, permission boundaries and organisation policies contribute to effective permissions.
AWS IAM Identity Center Documents workforce federation, permission sets and account access.
Microsoft Entra ID documentation Introduces Microsoft’s cloud identity, federation and access-management platform.
Azure role-based access control Explains Azure role assignments, security principals, role definitions and scopes.
Google Cloud IAM overview Introduces Google Cloud principals, roles, permissions, policies and resource hierarchy.
Google Cloud Workload Identity Federation Documents temporary cloud access for external workloads without permanent service-account keys.
GitHub Actions OIDC Explains how workflows can exchange OIDC identity for short-lived cloud credentials.
NIST SP 800-207: Zero Trust Architecture Explores identity-centred access decisions, continuous verification and the rejection of implicit trust based solely on network location.