Back to all posts

Cloud IAM

By on Mar 03, 2025

Tags:

Google Cloud Identity and Access Management (IAM) is a critical component of the Google Cloud Platform (GCP) that enables administrators to manage access to cloud resources effectively.

Cloud IAM Example:

I want to provide access to manage a specific cloud storage backet to a colleage of mine:

  1. Choose a Role with right permission (Ex: Storage Object Admin)
  2. Create Policy binding member (your friend) with role (permissions)

Important Generic Concept

  • Memeber: My colleage
  • Resource: Specific cloud storage bucket
  • Action: Upload / Delete Object

In Google Cloud IAM:

  • Roles: a set of permissions (to perform specific actions on specific resources)
  • How do you assign permission to a member?
    • Policy: You assign (or bind) a role to a member

IAM Roles

Role are permissions: Perform some set of actions on some set of resources

Three Types:

  • Basic Roles (Primitive roles) – Owner/Editor/Viewer
    • Viewer(role.viewer) – Read-only actions
    • Editor(role.editor) – Viewer + edit actions
    • Owner (role.owner) – Editor + Manage Roles and Permissions + Billing
    • EARLIEST VERSION: Created before IAM
    • NOT RECOMMENDED: Don’t use in production
  • Predefined Roles – Fine grained roles predefined and managed by Google
    • Dierent roles for dierent purposes
    • Examples: Storage Admin, Storage Object Admin, Storage Object Viewer, Storage Object Creator
  • Custom Roles – When predefined roles are NOT sufficient, you can create your own custom roles

Predefined Roles

Imaportant Cloud Storage Roles:

  • Storage Admin (roles/storage.admin)
    • storage.buckets.*
    • storage.objects.*
  • Storage Object Admin (roles/storage.objectAdmin)
    • storage.objects.*
  • Storage Object Creator (roles/storage.objectCreator)
    • storage.objects.create
  • Storage Object Viewer (roles/storage.objectViewer)
    • storage.objects.get
    • storage.objects.list

IAM policy

Policy: Assign permission to Members

  • Map Roles (What?), Members (Who?) and conditions (Which Resources?, When?. Form Where?)
  • Remember: Permissions are NOT directly assigned to Member
    • Permissions are represented by a Role
    • Member gets permissions through Role!
  • Roles are assigned to users through IAM Policy documents
  • Represented by a policy object
    • Policy object has list of bindings
    • A binding, binds a role to list of members
  • Member type is identified by prefix:
    • Example: user, serviceaccount, group or domain

IAM policy – Example

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:you@in28minutes.com",
        "serviceAccount:myAppName@appspot.gserviceaccount.com",
        "group:administrators@in28minutes.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:you@in28minutes.com"
      ],
      "condition": {
        "title": "Limited time access",
        "description": "Only up to Feb 2022",
        "expression": "request.time < timestamp('2022-02-01T00:00:00.000Z')"
      }
    }
  ]
}

Service Accounts

Service accounts in Google Cloud Platform (GCP) are specialized accounts used by applications or virtual machines (VMs) t interact with other GCP servers without human interventions

Exam of email address of service account:

id-compute@developer.gserviceaccount.com

Account Types

Default service account – Automatically created when some services are used

  • (Not Recommeded) has editor role by default

User Managed – user created

  • (Recommeded) Provide fine grained access control

Google-Managed Service accounts – Created and managed by Google

  • Used by GCP to perform operations on user’s behalf
  • In general, we DO NOT worry about them

Use case 1 : VM <-> Cloud Storage

  • Create a Service Account Role with the right permissions
  • Assign Service Account role to VM instance
  • Uses Google Cloud-managed keys:
    • Key generation and use are automatically handled by IAM when we assign a service account to the instance
    • Automatically rotated
    • No need to store credentials in config files
  • Do NOT delete service accounts used by running instances:
    • Applications running on those instances will lose access!

    Use case 2 : On Prem <-> Cloud Storage (Long Lived)

    You CANNOT assign Service Account directly to an On Prem App

    • Create a Service Account with right permissions
    • Create a Service Account User Managed Key
      • gcloud iam service-accounts keys create
      • Download the service account key file
        • Keep it secure (It can be used to impersonate service account)!
    • Make the service account key file accessible to your application
      • Set environment variable GOOGLE_APPLICATION_CREDENTIALS
        • export GOOGLE_APPLICATION_CREDENTIALS=”/PATH_TO_KEY_FILE”
    • Use Google Cloud Client Libraries
      • Google Cloud Client Libraries use a library – Application Default Credentials (ADC)
        • ADC uses the service account key file if env GOOGLE_APPLICATION_CREDENTIALS exists!

    Service Account Use Case Scenarios

    Scenario 1: Application on a VM wants to talk to a Cloud Storage bucket

    • Solution: Configure the VM to use a Service Account with right permissions

    Scenario 2: Application on a VM wants to put a message on a Pub Sub Topic

    • Solution: Configure the VM to use a Service Account with right permissions

    Scenario 3: Is Service Account an identity or a resource?

    • Solution: It is both. You can attach roles with Service Account (identity). You can let other members access a SA by granting them a role on the Service Account (resource).

    Scenario 4: VM instance with default service account in Project A needs to access Cloud Storage bucket in Project B

    • Solution: In project B, add the service account from Project A and assign Storage Object Viewer Permission on the bucket

    ACL (Access Controll Lists)

    ACL: Define who has access to yout bucket and objects as well as what level of access they have.

    How this defferent from IAM?

    • IAM permission apply to all objects with a bucket
    • ACLs can be used to customize specifix accessess to different objects

    User gets access if he is allowed by either IAM or ACL!

    (Remember) Use IAM for common permissions to all objects in a bucket

    (Remember) Use ACLs if you need to customize access to individual objects

    Signed URL

    You would want to allow a user limited time access to your objects:

    • Users do NOT need Google accounts

    Use Signed URL functionality

    • A URL that gives permissions for limited time duration to perform specific actions