Episode 49 · Module 10 · Infrastructure

Cloud IAM and Least Privilege

19 May 2026 · 9:33 · Security for Legal SaaS

9:33 9:33

Every cloud resource your legal SaaS platform depends on — databases, storage buckets, message queues, AI services, compute instances — is protected by an Identity and Access Management (IAM) system. IAM determines who can access what, under what conditions, and with what permissions. It is the control plane for your entire cloud infrastructure. The theory is straightforward: every principal (user, service, application) should have only the minimum permissions required to perform its function. This is the principle of least privilege, which we first discussed in Episode 8 in the context of database access.

Today’s Lesson

Security for Legal SaaS — Episode 49: Cloud IAM and Least Privilege

That Service Account Has Owner Permissions Because Someone Needed It Once

The theory is straightforward: every principal (user, service, application) should have only the minimum permissions required to perform its function. This is the principle of least privilege, which we first discussed in Episode 8 in the context of database access. Applied to cloud infrastructure, it means your document processing service should be able to read from the document storage bucket and write to the processed output bucket — and nothing else. Not access the database. Not read other services' logs. Not modify IAM policies.

The reality is different. Research on cloud security patterns ¹ consistently finds that over-permissioned cloud roles are the norm, not the exception. A developer needed broad access during initial setup, granted their service account Owner or Administrator permissions, moved on to the next task, and never scoped it down. Now every compromised container runs as God.

How Cloud IAM Works — Principals, Policies, and Permission Evaluation

All three major cloud providers — AWS, Google Cloud (GCP), and Microsoft Azure — use the same conceptual model, with different terminology:

Concept	AWS	GCP	Azure
Identity	IAM User, IAM Role	Google Account, Service Account	Azure AD User, Managed Identity
Permission	IAM Policy (JSON)	IAM Role binding	Role Assignment (RBAC)
Resource scope	Account-level, resource-level	Project, folder, organisation	Subscription, resource group
Machine identity	IAM Role (assumed by EC2/Lambda)	Service Account	Managed Identity

The permission evaluation chain follows a common pattern: when a principal attempts an action on a resource, the IAM system checks all applicable policies. In AWS, this means evaluating identity-based policies, resource-based policies, permission boundaries, session policies, and service control policies. A single `Deny` anywhere in the chain overrides all `Allow` statements.

Google Cloud's service account best practices ² emphasise that "service accounts are not just a mechanism for authentication — they define the permissions envelope for everything running under that identity." Every container, every serverless function, every background job running as a given service account inherits all of that account's permissions.

Service Accounts and Workload Identity — Machines Need Identities Too

In a legal SaaS platform, most API calls are made not by humans but by services: the document parser calling the storage API, the AI engine calling the model endpoint, the billing service writing to the database. Each of these services needs an identity to authenticate, and that identity must be tightly scoped.

Common anti-pattern: A single "app" service account shared by all microservices, with permissions to access every resource in the project. If any one service is compromised, the attacker inherits the combined permissions of every service. This is the blast radius problem — the scope of damage from a single breach.

The correct approach is one service account per service, each with the minimum permissions required:

Service	Needs	Should NOT Have
Document Parser	Read from upload bucket, write to parsed output bucket	Database access, IAM admin
AI Engine	Call model API, read from parsed output bucket	Direct storage access, billing data
Billing Service	Write billing records to database	Document access, model API access
Audit Logger	Write to audit log storage	Read any other data
Admin API	Read/write user management database	Direct access to document storage

The Cyscale IAM best practices guide ³ recommends creating service accounts with names that describe their purpose (`sa-document-parser`, `sa-billing-writer`) and reviewing their permissions quarterly.

Workload Identity Federation

Modern cloud platforms offer workload identity — a mechanism where your Kubernetes pods, CI/CD pipelines, or serverless functions receive cloud credentials automatically, without storing long-lived keys. GCP Workload Identity Federation ⁴, AWS IAM Roles for Service Accounts (IRSA), and Azure Workload Identity all eliminate the need for service account key files — which are long-lived credentials that can be stolen, copied, and reused from anywhere.

Temporary Credentials and Role Assumption

Long-lived credentials — API keys, service account key files, access keys that never expire — are a liability. If stolen, they provide indefinite access. If leaked to a log file, a configuration dump, or a developer's notebook, they remain valid until manually revoked.

The principle-of-least-privilege guide from Inventive HQ ⁵ emphasises temporary credentials as a core IAM practice:

AWS: Use IAM Roles and `AssumeRole` for temporary credentials (default: 1 hour). Use `aws sts get-session-token` for CLI access with expiration.
GCP: Service account keys should be avoided entirely. Use Workload Identity for GKE workloads and service account impersonation for developer access.
Azure: Use Managed Identities for Azure resources. For developer access, use `az login` with Azure AD — no stored credentials.

For legal SaaS platforms, the rule is simple: if a credential doesn't have an expiration time, it's a risk. Temporary credentials that automatically rotate eliminate an entire class of vulnerabilities — stolen keys, leaked credentials, forgotten access.

Over-Permissioned Cloud Roles — The Real-World Pattern

Security Boulevard's analysis of permission creep ⁶ documents the pattern: permissions accumulate over time. A developer needs access to debug a production issue — they're granted a broad role. The issue is resolved, but the permissions remain. Six months later, that developer's account has accumulated permissions across eight projects, including resources they no longer work with.

The statistics are stark: 23% of all cloud security incidents stem from misconfigurations ⁶, with overly permissive access policies being a leading cause. Permission creep — the gradual accumulation of excessive and unused cloud permissions — creates a dangerous attack surface that is difficult to manage manually.

Detecting Over-Permission

Each cloud provider offers tools to identify unused and excessive permissions:

Provider	Tool	What It Shows
AWS	IAM Access Analyzer ⁷	Unused permissions, excess privileges, external access findings
GCP	IAM Recommender ⁸	"Excess / Total permissions" — permissions the principal has but hasn't used
Azure	Microsoft Permissions Management ⁹	Over-provisioned identities, unused permissions, permission creep alerts

The GoCodeo guide to implementing least privilege ¹⁰ recommends a practical workflow: deploy with minimal permissions, let the application run for 30-90 days, then use IAM analyzers to identify permissions that were never used. Remove them. This "right-sizing" approach avoids the upfront difficulty of predicting exact permission needs.

Practical approach: Start with the broadest role that lets the service function (to avoid blocking development), then right-size after 30-90 days using IAM analyzers. This is pragmatic least privilege — you'll never get permissions perfect on the first try, but you should never leave them un-reviewed.

Privilege Escalation Inside Cloud Environments

IAM misconfigurations are not just about over-permission. They can be active attack paths. An attacker who compromises a service with permission to modify IAM policies can grant themselves any permission — effectively escalating from a limited role to full administrator access.

The shared responsibility model analysis ¹¹ highlights that cloud providers secure the platform, but IAM configuration is entirely the customer's responsibility. Common privilege escalation paths include:

IAM policy modification — a service with `iam:PutRolePolicy` in AWS or `setIamPolicy` in GCP can grant itself any permission
Role chaining — assuming a more privileged role from a less privileged one
Service account key creation — creating a new key for a privileged service account, gaining its permissions
Compute resource hijacking — launching a new instance or container with a more privileged role attached

For a legal SaaS platform, audit IAM-modifying permissions with special attention. Very few services should have the ability to change IAM policies. Separate the "create infrastructure" role from the "run application" role — and ensure the running application cannot modify its own permissions.

Just-in-Time (JIT) Access

For human operators who occasionally need elevated permissions — debugging a production issue, performing a database migration, responding to a security incident — just-in-time access provides temporary privilege elevation with automatic expiration.

Automated remediation approaches ¹ can automatically revoke unused permissions, tighten overly broad IAM policies, or trigger JIT access workflows. The pattern:

Operator requests elevated access through a ticketing system
Approval workflow (peer review, manager approval, or automated policy check)
Temporary role granted — typically 1-4 hours
All actions during the elevated session are logged
Role automatically revokes at expiration

This eliminates standing privileges — permissions that are always active, waiting to be exploited. For legal SaaS platforms handling privileged communications, JIT access is both a security control and an audit trail for regulator inquiries: who had admin access, when, for how long, and what did they do?

Key takeaway: Cloud IAM is the gatekeeper for your entire infrastructure. Over-permissioned service accounts are the most common and most dangerous misconfiguration in cloud environments. Use one service account per service, scope permissions tightly, prefer temporary credentials over long-lived keys, use IAM analyzers to detect permission creep, and implement JIT access for human operators. If a single compromised container can access every resource in your cloud project, your IAM configuration is your biggest vulnerability — not your application code.

What's Next

Next episode, we shift from infrastructure to the people who build on it — developer workstation security. Your production servers are hardened. Your developer's laptop has Slack, Chrome, and an SSH key to every environment.

Sources & references

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 49 — cloud IAM and least privilege. Alice, every legal SaaS platform runs on cloud infrastructure. IAM is the system that controls who can access what. But I suspect most teams don't give it the attention it deserves.

Alice: They don't. And the reason is that IAM is invisible when it's working. Nobody notices that the document parser can only read from the upload bucket and write to the output bucket. What they notice is when something is blocked — when a deployment fails because the service account doesn't have the right permission. And the path of least resistance in that moment is to grant a broad permission and move on. That's how you end up with service accounts that have Owner-level access to your entire cloud project — because someone needed it once, six months ago, and never scoped it down.

Dan: Mm. And Owner-level means...?

Alice: Everything. Full control over every resource — databases, storage, compute, networking, and IAM itself. A compromised container running as that service account can read every document in storage, query every database, modify IAM policies to grant itself even more access, and delete audit logs to cover its tracks. The blast radius of a single breach is your entire infrastructure.

Dan: Right. So IAM — what does that actually stand for, and how does it work?

Alice: Identity and Access Management. It's the system that answers three questions. Who are you — that's authentication, which we've covered extensively. What are you allowed to do — that's authorization, the permissions attached to your identity. And under what conditions — that might include time, location, or which resource you're accessing. Every cloud provider — AWS, Google Cloud, Azure — has its own IAM system, but they all follow the same pattern. You have principals — users and service accounts. You have policies that define what those principals can do. And you have resources that the policies apply to.

Dan: Mm-hmm. And service accounts are the machine identities? The identities that your services use to talk to cloud APIs?

Alice: Exactly. In a microservice architecture — which we discussed back in Episode 18 — your document parser, your AI engine, your billing service, your audit logger are all separate services. Each one needs to authenticate to cloud resources. Each one gets a service account. The critical question is: does each service get its own tightly scoped account, or do they all share one overly broad one?

Dan: Yeah, let me guess — the common pattern is one shared account with too many permissions.

Alice: <sigh> Almost universally. One service account called "app-service-account" with project-level Editor or Owner permissions, shared by every microservice. It's convenient. It never blocks deployments. And it means that if any single service is compromised — say, a vulnerability in your PDF parsing library — the attacker inherits the combined permissions of your entire platform. They can access client documents, query the database, call the AI model, and read billing records. All from one compromised service.

Dan: Hmm. So the fix is one account per service, each with just what it needs?

Alice: One account per service. The document parser gets read access to the upload bucket and write access to the output bucket. That's it. The AI engine gets permission to call the model API and read from the parsed document bucket. The billing service gets write access to the billing database. Each service's blast radius is limited to its own scope. A compromised document parser can't touch billing data or IAM policies.

Dan: Mm. What about the credentials themselves? How do services authenticate?

Alice: This is where many teams make a dangerous mistake. The traditional approach is a service account key file — a JSON file containing long-lived credentials. You download it, put it on the server, and the service uses it to authenticate. The problem: that key file never expires. If it's leaked — in a log file, in a configuration dump, in a developer's code repository — it provides access until someone manually revokes it. The modern approach is workload identity. Your cloud provider issues temporary credentials to your service automatically, based on where it's running. No key files to store, leak, or rotate. In GCP, that's Workload Identity Federation. In AWS, it's IAM Roles for Service Accounts. In Azure, it's Managed Identities.

Dan: Right. Temporary credentials that expire. That's a much smaller window for an attacker.

Alice: Typically one hour. If stolen, the credential is useless after it expires. Compare that to a key file that's valid indefinitely. For legal SaaS platforms, the rule is simple: if a credential doesn't have an expiration time, it's a risk. Eliminate long-lived credentials wherever possible.

Dan: Mm-hmm. Now, you mentioned permission creep. How does that happen in practice?

Alice: Gradually. A developer needs access to debug a production issue. They're granted a broad role — Editor or Administrator. The issue is resolved, but the permissions stay. Six months later, that developer's account has accumulated permissions across multiple projects, including resources they no longer work with. Multiply that by every developer, every service account, every one-off script. The research is clear — 23% of cloud security incidents come from misconfigurations, with overly permissive access as a leading cause.

Dan: Right. So how do you detect and fix it?

Alice: Every cloud provider has tools for this. AWS has IAM Access Analyzer, which shows unused permissions and excess privileges. Google Cloud has IAM Recommender, which compares granted permissions against actual usage and recommends reductions. Azure has Permissions Management, which flags over-provisioned identities. The practical workflow is: let your services run for 30 to 90 days, then use these analysers to identify permissions that were never used. Remove them. You'll never get permissions perfect on the first try, but you should never leave them un-reviewed.

Dan: Mm. And for humans who occasionally need higher access — like during an incident?

Alice: Just-in-time access. Instead of giving someone permanent admin permissions "in case they need it," you set up a workflow where they request elevated access when they actually need it. The request goes through an approval process. They get temporary admin access for one to four hours. Everything they do during that window is logged. The access revokes automatically when time expires. No standing privileges waiting to be exploited.

Dan: Yeah, that's the same idea as the temporary credentials — make everything time-bound.

Alice: Exactly. And for legal SaaS specifically, JIT access provides a clean audit trail. When a regulator or client asks "who had admin access to the systems holding our documents, and when?" — you can answer precisely. Not "these twelve people have permanent admin access," but "admin access was granted three times in the last quarter, for specific incidents, for specific durations, and here are the audit logs of every action taken."

Dan: Mm-hmm. One more thing — you mentioned that IAM misconfigurations can be actual attack paths, not just passive risks?

Alice: Yes. If a compromised service has permission to modify IAM policies — even if it was granted for some legitimate automation — the attacker can use that to grant themselves any permission. They escalate from a limited document-parser identity to full administrator. Other paths include creating new keys for more privileged service accounts, or launching new compute resources with more privileged roles attached. The defensive rule is: audit IAM-modifying permissions with extreme care. Very few services should have the ability to change permissions. Separate the "create infrastructure" role from the "run application" role, and make sure running applications cannot modify their own permissions.

Dan: Strong finish. Next episode — developer workstation security. Your production servers are hardened, but your developer's laptop has Slack, Chrome, and an SSH key to every environment.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.