GCP Identity and Access Management

Details

Google Cloud Identity and Access Management (IAM) enables secure, detailed control over who can do what on which cloud component. It's the gatekeeper layer, ensuring only the right people or applications perform the right tasks.

What Does IAM Do?

IAM defines permissions for accounts interacting with cloud objects. It governs:

• Which identities can view, create, or alter resources
• What scope of actions is allowed
• Where the policies apply (project, folder, org)

This fine-grained model enables least-privilege principles, reducing exposure and limiting accidental changes.

Types of Identities

IAM recognizes a range of actors:

• User Accounts: Personal emails (e.g., john@gmail.com)
• Service Accounts: Machine-controlled identities for backend apps
• Groups: User clusters from enterprise identity systems for shared access control.
• Workload Identity Federation: Grants external clouds access to GCP using token-based trust without keys.

Access Levels

IAM access is defined by binding roles to identities over resources. These authorizations are inherited hierarchically:

• Organization Level: Root layer of control
• Folder Level: Logical subdivisions of projects
• Project Level: Common for teams, apps, workloads
• Resource Level: Instance, bucket, or service level access

IAM Roles

Roles bundle one or many permissions. GCP offers three main types:

1. Primitive Roles

• Broad and legacy roles: Owner, Editor, Viewer
• Affect entire project scope

2. Predefined Roles

Curated by Google

Tailored to specific services like:

• roles/compute.instanceAdmin
• roles/storage.objectViewer

3. Custom Roles

• Crafted by the user
• Include only selected privileges
• Ideal for granular control

Policy Binding Example

Let’s say you want to grant a user read-only access to a Cloud Storage bucket:

gcloud projects add-iam-policy-binding my-project \   
      --member="user:alice@example.com" \   
      --role="roles/storage.objectViewer"

IAM Conditions

With IAM Conditions, access is controlled based on dynamic attributes like:

• Time of day
• IP address range
• Resource type
• Security level of the request

Example: Allow file access only during business hours from a corporate IP.

Service Accounts

Service accounts are non-human identities used by applications and automated processes. These accounts authenticate between services.

Used in:

• APIs
• CI/CD pipelines
• Serverless executions
• Workload Identity integration

gcloud iam service-accounts create deploy-bot \   
      --description="Automated deployment identity"

IAM Policies Structure

Each access rule is structured using:

• Members: identities (users, groups, accounts)
• Roles: list of actions allowed
• Resources: target objects (VMs, buckets, etc.)

All these elements together form the policy binding, defining how access is granted.

Auditing and Monitoring

To ensure accountability, IAM actions are logged in Cloud Audit Logs. Admins can track:

• Role changes
• Policy modifications
• Access attempts
• Unauthorized actions

This helps detect misuse, enforce compliance, and monitor policy drift.

Best Practices

• Apply minimum required permissions
• Use groups instead of assigning users individually
• Create custom roles for sensitive workflows
• Use IAM Conditions to fine-tune trust

---

Conclusion

GCP IAM offers a robust, policy-driven method for handling permissions across cloud assets. By combining identity recognition, role delegation, and detailed control rules, it helps maintain safe, organized, and predictable access behavior in the cloud ecosystem.