GCP IAM

IAM, or Identity and Access Management, is a crucial component of Google Cloud Platform (GCP) that allows management and control of access to GCP resources. In general, it’s about who has what access for which resource. A quick overview (in part copied from Google’s IAM Overview):

1. Identity:
   • Principals: IAM identifies users, groups, and service accounts as “principals.”
   • A principal can be a Google Account (for end users), a service account (for applications and compute workloads), a Google group, or a Google Workspace account or Cloud Identity domain that can access a resource. Each principal has its own identifier, which is typically an email address.
2. Roles:
   • A role is a collection of permissions. Permissions determine what operations are allowed on a resource. When you grant a role to a principal, you grant all the permissions that the role contains. IAM uses predefined roles (e.g., Viewer, Editor, Owner) that grant a ready-made set of permissions.
   • Custom roles can be created to define specific sets of tailored permissions.
3. Policy:
   • The allow policy is a collection of role bindings that bind one or more principals to individual roles. When you want to define who (principal) has what type of access (role) on a resource, you create an allow policy and attach it to the resource. Essentially, you don’t “give” permissions to principals as much as you bind them to certain roles (or groups) which have those permissions.
4. Permissions:
   • Specific actions that can be performed on GCP resources, such as reading or writing data, creating instances, etc.
5. Resource Hierarchy:
   • IAM policies are applied at the resource level within the GCP hierarchy.
   • The hierarchy includes organizations, folders, projects, and resources.
6. Principles of Least Privilege:
   • IAM follows the principle of least privilege, ensuring that principals have the minimum necessary permissions to perform their tasks.
7. Conditional IAM:
   • IAM supports conditions that allow further control when a policy should be applied based on certain conditions (e.g., IP address, time of day).

Basic Commands

Give a principal (member) a certain role within a project:

gcloud projects add-iam-policy-binding my-project-id \
    --member=user@example.com \
    --role=roles/editor

IAM Objects

• Organization
• Folders
• Projects
• Resources
• Roles
• Members

Each child in the IAM resource hierarchy has exactly one parent.

Roles

• IAM basic roles offer fixed, coarse-grained levels of access
  • Owner
    • Invite members
    • Remove members
    • Delete projects
    • (includes Editor…)
  • Editor
    • Deploy applications
    • Modify code
    • Configure services
    • (includes Viewer…)
  • Viewer
    • Read-only access
  • Billing Administrator
    • Manage billing
    • Add and remove administrators
• IAM predefined offer more fine-grained permissions on particular services
  • InstanceAdmin Role
    • List of permissions necessary perform specific tasks…
  • ComputeAdmin
    • Full control of all Compute Engine resources
  • NetworkAdmin
    • Permissions to create, modify, and delete networking resources, except for firewall rules and SSL certificates
  • StorageAdmin
    • Permissions to create, modify, and delete disks, images, and snapshots
• IAM custom allows for a more precise set of permissions (least privilege model)
  • Custom rules are NOT updated automatically. When new features and permissions are rolled out in GCP, these won’t necessarily feature in your custom role.

Members

Types of members

• Google Account (personalized)
• Service Account (machines that run code)
• Google Group (a bundle of accounts that share a policy)
• Cloud Identity or Google Workspace Domain (top organizational entity)

Policy

• A policy consists of a list of bindings
• A binding binds a list of members to a role
• Child policies cannot restrict access granted at the parent level.
  • Example: if you are given Editor role for Department X (folder), and you are given the Viewer role of bookshelf project (within folder), the Editor permissions override the Viewer ones.
• Deny Policies can deny permissions (and can override granted). Can also be determined by conditions.
  • Example: granting or denying temporary access to a user.