Cloud Identity and Access Management: Who Can Do What?

Cloud platforms expose powerful APIs.

One authorized request can create servers, copy databases, change firewall rules, read secrets, or delete storage. Identity and Access Management determines which principal can perform which action on which resource under which conditions.

Cloud IAM should grant the smallest practical permissions to a clearly identified human or workload.

Identity is the foundation; network location alone is not enough.

A concrete example: a deployment role

A deployment pipeline needs to update one application service.

Its role allows:

upload a new application artifact,
update that service,
read deployment status,
and roll back revisions.

It cannot:

read payroll storage,
create IAM administrators,
disable audit logs,
or delete unrelated databases.

Compromise remains serious but contained.

Principals

A principal is an identity making a request.

Examples include:

human user,
group,
service account,
application role,
virtual machine identity,
external organization,
or federated session.

Shared user accounts weaken attribution and lifecycle control.

Authentication and authorization

Authentication establishes which principal is acting.

Authorization evaluates whether that principal may perform the requested action. Strong multi-factor login does not justify broad permissions; both controls are needed.

Policies should be evaluated at every protected cloud API boundary.

Policies

A policy commonly describes:

effect: allow or deny,
actions,
resources,
conditions,
and principal or attachment.

Example concept:

Allow read on reports/team-a/* when request uses company network.

Policy languages are precise and can contain surprising wildcard behavior.

Identity-based policies

An identity-based policy attaches permissions to a user, group, or role.

It answers:

What can this principal do?

Groups simplify human access by role, while workload roles define machine capabilities.

Resource-based policies

A resource-based policy attaches to a bucket, queue, key, or other resource.

It answers:

Who can access this resource?

Cross-account access often uses resource policy and identity policy together. Both sides of the trust relationship should be reviewed.

Explicit deny

Many IAM systems support explicit deny that overrides allows.

Organizations use it for guardrails:

prevent public storage,
deny activity outside approved regions,
protect audit logs,
or block disabling security controls.

Deny rules need testing because an overly broad condition can interrupt legitimate recovery.

Least privilege

Least privilege means granting only required actions and resources for the necessary time.

It is iterative:

define the job,
grant a narrow starting set,
observe legitimate denials,
add exact permissions,
review unused rights,
remove obsolete access.

Starting with administrator and promising to reduce later often leaves permanent excess.

Roles

A role is an assumable permission set rather than a permanent person.

Humans can assume roles for:

development,
billing,
security review,
or incident response.

Workloads can assume service roles. Sessions are temporary and can carry context such as user, device, or ticket.

Short-lived credentials

Temporary credentials expire automatically.

They reduce risk compared with long-lived access keys stored in laptops, code, or CI settings. Federation and workload identity issue credentials when needed.

Expiration does not fix excessive permissions, but it limits usefulness after theft.

Human federation

Connect cloud accounts to an organizational identity provider.

This centralizes:

employment lifecycle,
multi-factor policy,
device controls,
group assignment,
and sign-in auditing.

Avoid creating independent permanent cloud users for every employee unless a specific recovery need exists.

Workload identity

Applications should prove identity through their runtime environment.

A VM, container, or function receives credentials for its assigned role. The application does not need a static key file.

Protect metadata and token endpoints so one compromised workload cannot steal another identity.

Service accounts

Service accounts need:

named owner,
clear purpose,
narrow role,
rotation or federation,
activity monitoring,
and removal when unused.

"Automation account" is not sufficient ownership for a credential that can alter production.

Conditions

Policies can restrict access by:

time,
source network,
device state,
region,
resource tags,
encryption use,
multi-factor presence,
or session attributes.

Conditions add precision but also complexity. Test both allowed and denied scenarios.

Tags and attribute-based access

Attribute-based access can express rules such as:

A team role may manage resources tagged with the same team.

This scales better than listing every resource individually, but tag creation and modification become security-sensitive. A principal must not simply retag a protected database into its own scope.

Permission boundaries and guardrails

Organizations can limit the maximum permissions a team or account can grant.

Guardrails prevent local administrators from escaping required policy. They should preserve emergency and deployment workflows deliberately.

Central controls need clear ownership and change review.

Secrets versus permissions

A secret gives access to one credential or value. IAM decides who can retrieve or use it.

Do not give every workload broad secret-manager read access. Bind each application to its required secrets or, better, use direct service identity where possible.

Secret storage does not correct overly broad retrieval permission.

Break-glass access

Emergency access may be needed when normal identity systems fail.

Break-glass credentials should be:

strongly protected,
rarely used,
monitored,
tested,
time-limited where possible,
and reviewed after every use.

An inaccessible emergency account is useless; a convenient daily-use one is no longer emergency-only.

Audit logs

Cloud audit logs should record:

principal,
action,
resource,
time,
source,
result,
and session context.

Protect logs from alteration and centralize them outside ordinary workload control.

Access reviews

Regularly review:

inactive users,
unused permissions,
dormant keys,
cross-account trust,
public resource policies,
and high-privilege role assumptions.

Access accumulates as people and systems change unless removal is an explicit process.

Testing IAM

Test negative cases:

deployment role cannot read unrelated data,
developer cannot disable logs,
expired session fails,
cross-account principal lacks unapproved actions,
and resource tags cannot bypass boundaries.

IAM correctness includes proving denial, not only proving that work succeeds.

Knowledge check

What is a principal in cloud IAM?
How do identity-based and resource-based policies differ?
Why are short-lived credentials safer than permanent keys?
What risk appears when access depends on resource tags?
Why should IAM tests include denied actions?

The one idea to remember

Cloud IAM connects verified principals to narrowly scoped actions, resources, and conditions. Prefer roles, federation, and short-lived workload identity, enforce guardrails, protect audit evidence, and continuously remove permissions that no longer serve a named purpose.