Cloud Identity: IAM Roles and Service Accounts

In cloud environments, identity is the new perimeter. Every action — starting a VM, reading a database, calling an API — is authorized based on the calling identity. Cloud IAM (Identity and Access Management) systems define who can do what on which resources. Unlike on-premises environments where network location provided implicit trust, cloud IAM treats every request as requiring explicit authorization regardless of where it originates.

AWS IAM has three primary identity types. IAM Users represent individual humans or applications with long-term credentials (access key + secret key). IAM Groups bundle users and assign shared permissions. IAM Roles are identities with temporary credentials that can be assumed by users, AWS services (EC2, Lambda), or other accounts. Roles are preferred over long-term access keys because their credentials expire automatically, reducing the risk of credential exposure.

IAM policies define what actions an identity may perform on which resources. The least privilege principle demands that policies grant only the specific actions needed for the task. Common violations: using * wildcards for actions (grants all actions in a service), using * for resources (grants access to all resources), and attaching overly broad managed policies like AdministratorAccess to service accounts. Every wildcard should be justified and regularly reviewed.

In Google Cloud Platform (GCP), non-human workloads authenticate using service accounts — managed identity entities with JSON key files or Workload Identity Federation. Each service account should follow least privilege: bind it only to the GCP services it needs to call. Service account keys (JSON files downloaded from the console) are long-lived credentials that must be treated like passwords — rotated regularly and never committed to source code or uploaded to public repositories.

Azure Managed Identities (formerly MSI) are the Azure equivalent of AWS IAM roles for services — they allow Azure resources (VMs, App Services, Functions) to authenticate to Azure APIs without storing credentials. There are two types: System-assigned managed identities are tied to a specific resource and deleted when the resource is deleted. User-assigned managed identities are standalone objects that can be shared across multiple resources. Managed identities eliminate the need for any stored keys or secrets.

Long-lived credentials — static access keys, API tokens, and service account key files that never expire — are one of the highest-risk elements in cloud environments. If leaked (via GitHub, S3 bucket, logs, or a compromised developer laptop), these credentials grant immediate access until manually revoked. Organizations should: audit all long-lived credentials, rotate them on a schedule, prefer role-based or federated access that produces short-lived tokens, and alert immediately when credentials appear in public repositories.

IAM privilege escalation occurs when an identity uses a combination of permissions to grant itself additional permissions. Classic escalation paths include: attaching a more permissive policy to your own user, creating a new IAM user with elevated permissions, passing a role (iam:PassRole) to a service, and updating a Lambda function's execution role. AWS's IAM Access Analyzer can detect these patterns, and IAM permission boundaries can hard-limit the maximum permissions any identity can be granted.

Cloud organizations often use multiple accounts (dev, staging, prod, security) as blast-radius boundaries. Cross-account role assumption allows identities in one account to assume roles in another — enabling centralized tooling to operate across accounts. Security controls include: requiring an External ID in the trust policy to prevent confused deputy attacks, restricting which accounts can assume a role via the Principal ARN, and logging all cross-account assumptions in CloudTrail for audit purposes.

AWS EC2 instances can retrieve their IAM role credentials from the Instance Metadata Service (IMDS) at http://169.254.169.254. The SSRF vulnerability class is particularly dangerous here: if an application is vulnerable to SSRF, an attacker can exfiltrate the instance's IAM role credentials by making the server fetch from the IMDS URL. IMDSv2 (requiring a session token) mitigates SSRF-based credential theft and should be enforced on all EC2 instances.

IAM Access Analyzer (AWS) automatically identifies resources shared with external principals and IAM policies that grant more than intended. It analyzes bucket policies, role trust policies, and KMS key policies to flag external access that was not explicitly intended. Regular IAM policy reviews — manually or with tools like Cloudsplaining, PMapper, or Permissions Boundary Analyzer — are essential to identifying privilege escalation paths before attackers find them.

Workload Identity Federation allows external workloads (GitHub Actions, on-premises systems, other cloud providers) to authenticate to cloud IAM using short-lived OIDC tokens instead of long-lived service account keys. A GitHub Actions workflow can assume an AWS IAM role using its OIDC token for the duration of the job, then the token expires. This approach eliminates the entire class of long-lived credential leakage from CI/CD pipelines.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: IAM roles provide temporary credentials and are preferred over long-lived access keys for cloud workloads, least-privilege policies should avoid wildcards and grant only specific actions on specific resources, and IMDSv2, permission boundaries, and workload identity federation eliminate common credential exposure paths. Next up we explore Cloud Security Posture Management (CSPM).