IAM

Identities and Roles

Principals	4 types of Principals: Two special members: allAuthenticatedUsers: everyone authenticated to GCP, not just in your Org allUsers: anyone on the internet, authenticated or not
Roles	Set of permissions grouped together, each one representing a fine grained operation Boundaries Can set limits on the roles that a member can grant: let you create limited IAM admins who can manage their own team's IAM policies, but only within the boundaries set IAM Conditions: you can attach conditions to role bindings. For example you can set an expiration time, or you can scope down the binding to affect only certain resources matching a pattern Types: Primitive (Basic) Roles Applied across all resources in a project Managed by Google, so the set of permissions can change over time Can assign ACL grants (legacy authz system for Buckets/BigQuery) to those bound to a primitive role in the Project Predefined roles Apply to a particular GCP service in a project Provide granular access for a specific service Managed by Google Custom Roles
Policies	Each policy contains a set of roles and role members Policies are inherited downwards in the hierarchy Resource policies are a UNION of parent and resource: Policies implemented at a higher level in the hierarchy can't take away access that's granted at a lower level If a parent policy is less restrictive, it overrides a more restrictive resource policy If a parent policy is more restrictive, it does not override a less restrictive resource policy

Policy Evaluation

Service Accounts

General Info

• Identified with an email address:
  • [email protected]
  • [email protected]
• Service accounts authenticate using keys
• You can assign a predefined or custom role to a service account

Types

Type	Description
User Managed	Manually created by users, alongside a private key Google only stores the public portion of a user-managed key Keys lifecycle is your responsibility
Google Managed	All service accounts have Google-managed keys Google stores both the public and private portion of the key No need to generate keys for them Private keys are never directly accessible Applications can just assume their identity Example: Each Project comes with a default service account that is used by Compute Engine (GCE) services (assigned the Project Editor role) VMs will transparently be identified by that service account, and they are authorized to request short-lived authorization tokens from the internal metadata service

Structure of a Service Account Key

{
  "type": "service_account",
  "project_id": "project-id",
  "private_key_id": "key-id",
  "private_key": "-----BEGIN PRIVATE KEY-----\nprivate-key\n-----END PRIVATE KEY-----\n",
  "client_email": "service-account-email",
  "client_id": "client-id",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/service-account-email"
}

Access Scopes

• Access scopes provide the ability to limit what permissions are allowed when using the GCE default service account
• Although is better to use a custom SA with IAM roles
• Only apply on a per-instance basis (instance must be stopped to change it)

Options

Scope	Description
Allow default access	Read-only access to storage, access to Stackdriver logging and monitoring
Allow full access	Grant full access to all Cloud APIs
Set access for each API	Grant access to only the APIs required by the programs running on the VM

Other Useful Services

Service	Description
Workload Identity federation	General Info Keyless application authentication mechanism that allows workloads running on-premises, in AWS, or in Azure to federate with an external Identity provider (IdP) and call Google Cloud resources without using a service account key Workloads instead call GCP's security token service (STS) endpoint to exchange the authentication token they obtained from the IdP for a short-lived GCP access token Workloads then use this access token to impersonate a service account and inherit the permissions of the service account to access GCP resources Setup Process Create a workload identity pool resource object (the pool acts as a container for the collection of external identities) Connect one or more IdPs to the workload identity Pool. The IdP can be an AWS or Azure account(s) or provider(s) that support OIDC protocol Grant the pool access to resources by defining two IAM policies A policy granting a service account access to desired resources. You can create a new service account or re-use an existing service account A policy that allows identities from the pool to impersonate the service account Authenticate workloads to the STS endpoint, impersonate the service account, and have them call the desired GCP APIs See also: Best practices for using workload identity federation
Cloud IAM recommender	Helps enforce the principle of least privilege by ensuring that members have only the permissions that they actually need Functioning Compares project-level role grants with permissions used within the last 90 days If a permission has not been used within that time, recommender will suggest revoking it Gives three types of recommendations: Revoke an existing role Replace an existing role Add permissions to an existing role Guides Enforcing least privilege by bulk-applying IAM recommendations (repo) How lateral movement insights are generated
IAM Policy Simulator	Lets you see how an IAM policy change might impact a member's access before you commit to making the change
IAM Policy Troubleshooter	Helps more closely examine policies that govern user access to a particular resource Makes it easier to understand why a user has access to a resource or doesn't have permission to call an API Functioning Requires a member email, a resource name, and a permission to check Examines all IAM policies that apply to that resource Reports on whether that member's roles include that permission to that resource Reports on which policies bind that member to those roles Limitations It will only access policies that the user has permissions to view If you do not have access to a resource policy, it will not be analyzed Maximum effectiveness requires the Security Reviewer (roles/iam.securityReviewer) role

---

1. Understanding roles ↩

2. Google Cloud IAM for Security Teams ↩

3. Google Cloud Service Accounts Security Best Practices ↩

4. Choose the best way to use and authenticate service accounts on Google Cloud ↩

5. Enable keyless access to GCP with workload Identity Federation ↩

6. Permissions Reference for GCP IAM ↩

7. Introducing IAM Deny, a simple way to harden your security posture at scale ↩