Identities represent who or what is making a request

An identity is the entity that signs in or authenticates to the cloud provider. In AWS the main identities are IAM users, IAM roles, and groups. Google Cloud uses principals that include user accounts, service accounts, and groups. After authentication the provider checks authorization against policies attached to the identity or the resource.

AWS recommends replacing long-term IAM user credentials with roles wherever possible. Human users should sign in through IAM Identity Center or federation and then assume a role. Service accounts and workloads also use roles to obtain temporary credentials rather than embedding permanent keys.

  • Root user: full access created with the account; avoid for daily use
  • IAM user: long-term credentials tied to one person or application
  • IAM role: assumable identity that grants temporary credentials
  • Service account (Google Cloud): identity for applications and VMs

Roles collect permissions for a purpose

A role is a named collection of permissions. You grant the role to a principal instead of assigning individual permissions. Google Cloud defines basic roles for broad access, predefined roles for specific services, and custom roles for exact needs. AWS uses managed policies and inline policies attached to roles or users.

Roles make it easier to change access for many principals at once. When a workload needs to read from an object store, attach a role that contains only the required read actions rather than giving full administrative rights.

  • Basic roles provide broad access and are rarely suitable for production
  • Predefined roles target one service and follow common job functions
  • Custom roles let you list only the permissions you need

Policies define the actual permissions

A policy is a document that states what actions are allowed or denied on which resources. AWS stores most policies as JSON. Google Cloud uses allow policies that bind roles to principals on a resource. When a request arrives the provider evaluates every applicable policy and reaches a final allow or deny decision.

Policies can be identity-based or resource-based. Identity-based policies travel with the user or role. Resource-based policies are attached directly to the bucket, queue, or other resource and can grant access to principals outside the account.

  • Start with the minimum actions required for the task
  • Use conditions to restrict access by IP range, time, or required MFA
  • Review policies regularly because requirements change

Temporary credentials reduce long-term risk

Temporary credentials expire after a set time and cannot be reused after expiration. AWS Security Token Service (STS) issues them when a role is assumed. Google Cloud also issues short-lived credentials for service accounts. Because the credentials are generated on demand you do not need to distribute or rotate static keys inside applications.

Temporary credentials support identity federation and workloads running on compute instances. The instance metadata service supplies the credentials automatically so code never stores secrets. Once the session ends or the token expires the credentials stop working.

  • Temporary credentials last from minutes to hours
  • They are generated dynamically and not stored with the user
  • No manual rotation is required after they expire

Least privilege limits blast radius

Least privilege means granting only the permissions required to complete a task. Begin with a narrow set of actions and add more only after monitoring shows they are needed. Both AWS and Google Cloud provide tools that report which permissions an identity actually uses so you can refine policies over time.

Starting with overly broad policies and tightening them later is less secure. Managed policies with wildcards can serve as a starting point, but they should be replaced with custom policies once usage patterns are understood. Regular audits prevent unused permissions from accumulating.

  • Monitor actual permission usage before writing final policies
  • Replace broad managed policies with scoped custom policies
  • Revisit policies after application changes or new features