6

Google Cloud Identity and Access Management

In this chapter, we will explore Google Cloud Identity and Access Management (IAM), an essential service to comprehend for the exam. With IAM, you can authorize cloud services, and assign appropriate access to users and applications. Acquiring a good understanding of IAM is crucial to ensure that your cloud implementation follows the principle of least privilege, restricting access to only what is necessary.

In this chapter, we will cover the following topics:

• Overview of IAM
• IAM roles and permissions
• Service accounts
• IAM policy bindings
• IAM conditions
• Cloud Storage, IAM, and ACLs
• Logging and IAM APIs

Overview of IAM

In the previous chapter, we discussed Cloud Identity and its role in authentication, user management, and device management in Google Cloud and Google Workspace. Now, let us explore IAM, which focuses on authorization in Google Cloud. Authorization is a key principle of cloud computing, addressing various requirements and ensuring secure access to resources. Some of the problems it solves are the following:

• How do I grant access to people and workloads?
• How do I provide time-bound access?
• How do I create service accounts with the least privilege?
• How do I enable services in a particular project but not others?
• How do I grant just the right access to users?
• How do I operate in multi-cloud environments?
• How do I find over-provisioned access?
• How do I troubleshoot access issues?

Figure 6.1 – IAM overview

In Figure 6.1, you can see how IAM works on the principle of who (identity) has what access...

Service accounts

Google Cloud service accounts are a critical part of the platform. A cloud resource or workload uses a specific type of account. To make API calls, an application deployed (for example, Compute Engine, App Engine, or GKE) or a workload (Dataproc, Dataflow, and so on) utilizes service accounts. Using a service account as an identity, the application can access cloud resources (either in the same or a different project) based on the role it has been assigned.

There are some main differences between a service account and a user account:

• Service accounts have no ability to log in to the Cloud console like a normal user.
• Public and private RSA key pairs are used to authenticate the service account and sign the API request.
• A service account can be impersonated by a human or another service account.
• Service accounts are not visible in Cloud Identity because they belong to the Google Cloud managed domain. While service accounts can be added to a Google...

IAM policy bindings

In Google Cloud, access is managed through an IAM policy binding. An IAM policy is attached to a particular resource (remember, a resource could be a service account). An IAM policy contains a collection of role bindings that associate with one or more principals.

Recall that a principal could be one or more of the following:

• A Google account (a Gmail account is a form of Google account)
• A service account
• A Google group
• A Google Workspace account
• A Cloud Identity domain
• All authenticated users
• All users

IAM policy bindings (sometimes simply called bindings) associate a role to the principals both on the resource that the policy is attached to and on all the resource’s descendants (for example, a policy attached to a folder is applicable to all the resources underneath that folder).

Policy structure

IAM policies consist of role definitions and additional details. A role binding determines the resources that can...

Tag-based access control

Tags are key-value pairs that can be attached to organizations, folders, or projects. They are an IAM construct and differ from labels and network tags. Tags follow an inheritance model, where a tag applied at the organization level is inherited by child objects, but this inheritance can be overridden if needed. Conditional IAM roles can be granted based on specific tags assigned to a resource.

In the resource hierarchy, tags are automatically inherited, but you can attach an additional tag to a resource to prevent it from inheriting a specific tag value. Essentially, each tag on an organization or folder sets a default value, which can be overridden by tags on lower-level resources such as folders or projects. Once tags are attached to a resource, you can define conditions to grant access based on those tags.

Tag structure

Here are how tags are structured in IAM:

• A tag is a key and value pair.
• A permanent ID, which is globally unique and...

Cloud Storage ACLs

Cloud Storage provides separate access control in addition to IAM. There are two ways, in fact: a more uniform way of doing access control via IAM and a legacy way of doing access control via fine-grained ACLs. Object ACLs do not appear in the hierarchy of IAM policies, so be aware of how your Cloud Storage buckets are controlled. When evaluating who has access to one of your objects, make sure you check the ACLs for the object, in addition to checking your project- and bucket-level IAM policies. This could get very convoluted, so the recommendation is to use uniform access control using IAM in most cases.

Access Control Lists (ACLs)

You can use an ACL to determine who has access to your buckets and objects, as well as what level of access they have. ACLs are applied to specific buckets and objects in Cloud Storage. There are one or more entries in each ACL. An entry enables a certain user (or group) to carry out specific tasks. Each entry is made up of two...

IAM APIs

IAM uses the following API endpoints (regular OAuth access tokens either for a user or service account can be used to access these APIs):

• Policies (v2)
• Roles (query and get/list)
• Organizations roles
• Permissions
• Projects
  • IAM policies (linting and querying)
  • Workload identity pools, operations, and providers
  • Permissions
  • Roles
  • Service accounts
  • Service account keys
• Service account credentials
• Security token services

Finally, let us look at various log files for IAM APIs. You will often start with these logs to troubleshoot an access issue.

IAM logging

Google Cloud IAM writes audit logs and admin logs to help with questions such as “Who did what, where, and when?” These logs are vitally important for audit and forensic capabilities.

For information on Admin Activity and Data Access read audit logs, please check the Google Cloud product documentation.

IAM audit logs use one of the following resource types:

• api: A request to list information about multiple IAM roles or policies
• audited_resource: A request to exchange credentials for a Google access token
• iam_role: An IAM custom role
• service_account: An IAM service account, or a service account key

Log name

Let us assume project_id = acme-project-id, folder_id = acme-folder, billing_account_id = 123456, and organization_id = 987654321:

 projects/acme-project-id/logs/cloudaudit.googleapis.com%2Factivity  projects/acme-project-id/logs/cloudaudit.googleapis.com%2Fdata_access  projects/ acme-project-id/logs /cloudaudit.googleapis...

Summary

In this chapter, we explored various powerful features of Cloud IAM, including principals, roles, IAM policies, and service accounts. We gained insights into effective service account key management and learned how to detect potential issues when keys are checked into Git. Additionally, we discovered the versatility of IAM conditions and adopted best practices for creating robust IAM policies. We also delved into Cloud Storage ACLs and their ability to provide fine-grained access control. Armed with this knowledge, you are now equipped to confidently set up IAM policies for any workloads in Google Cloud, troubleshoot access problems, and implement the recommended best practices we discussed. We even delved into advanced features such as IAM Policy Intelligence and WIF.

As we conclude this chapter on Google Cloud’s IAM features, the upcoming chapters will focus on exploring the robust network security capabilities of Google Cloud.

Further reading

• Attribute reference for IAM Conditions: https://packt.link/wMFb4
• Predefined ACLs for Cloud Storage: https://packt.link/jfhAt
• IAM Relation to Cloud Storage ACLs: https://packt.link/gQoHG
• Cloud Storage ACL behavior: https://packt.link/VgFY0
• Cloud Storage interoperability with AWS S3: https://packt.link/vqNy3
• Tags using conditions: https://packt.link/zzvld