Patterns and practices for identity and access governance on Google Cloud

Last reviewed 2024-07-11 UTC

There are a number of Google Cloud products and services that you can use to help your organization develop an approach for identity governance and access management for applications and workloads running on Google Cloud. This document is intended for security administrators, operations managers, and enterprise architects who work in customer teams and who want to learn about these tools and controls and how to use them.

This document assumes that you have the following:

A Google Cloud project.
A user account with administrative access to manage Cloud Identity groups and users. You need this access to run the example procedures in this document.
A user account without administrative access to manage Cloud Identity groups and users. You need this account to test some of the controls that you set in the example procedures in this document.

If you don't already have access to a Google Cloud project and administrative access to Cloud Identity, see Creating a Google Cloud project and Setting up Cloud Identity.

Discover unused accounts and permissions

It's a best practice to remove user accounts when they are no longer needed because unused (orphaned) user accounts and service accounts can pose a security risk. You can use Google Cloud Policy Intelligence in the following ways to help your enterprise understand and reduce risk:

Helping administrators in your enterprise discover accounts and permissions that aren't being used anymore, for reasons like an employee has left the company or changed roles.
Helping to identify service accounts that have been abandoned after the completion of tasks.

View and apply IAM recommendations

The Identity and Access Management (IAM) recommender is part of the Policy Intelligence suite of tools and services. It uses machine learning (ML) to make smart access control recommendations to help you identify accounts that no longer need access to Google Cloud resources. You can then review the recommendations and decide whether to apply them. IAM recommender also helps you to maintain the principle of least privilege across all the members in your organization. In addition to providing recommendations, the Recommender service uses ML to provide detailed insights. Insights are findings that highlight notable patterns in resource usage. For example, you can collect additional information about permission usage in your project, identify permissions that aren't being used and are no longer needed, and identify unused service accounts.

It's possible to view and apply IAM recommendations in the Google Cloud console at an enterprise-level scale. In the following example procedure, you use BigQuery to review and rightsize access permissions in your organization. To set up the BigQuery integration, you configure an export of recommendations made by IAM recommender to a BigQuery dataset. This data can then be queried and reviewed using visualization tools such as Looker Studio and Looker.

Implementation

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
BigQuery is automatically enabled in new projects. To activate BigQuery in a pre-existing project, enable the BigQuery API.

Enable the API
Configure the BigQuery Data Transfer Service to pull data from IAM recommender. To learn more, see Exporting recommendations to BigQuery.
Go to the BigQuery page.

Go to BigQuery
Copy and paste the following query into the Editor field:
```
SELECT
   recommendation_details
FROM PROJECT_ID.DATASET.TABLE_NAME
WHERE recommender = "google.iam.policy.Recommender"
AND recommender_subtype = "REMOVE_ROLE"
```
Replace the following:
- PROJECT_ID: the Google Cloud project ID that you are using to execute this example
- DATASET: the name of the dataset that you selected when setting up the BigQuery Data Transfer Service job.
- TABLE_NAME: the name of the table created by the BigQuery Data Transfer Service job.
You run this query to identify the recommender_subtype subtype of IAM RecommenderREMOVE_ROLE recommendations.
Click Run. You use the query result to identify unused roles and rightsize IAM role bindings.

You can save query results to Sheets. To learn more, see Saving query results to Sheets.

Give users the ability to request access to resources

Enterprise administrators need the ability to let users request access to resources. Typically, these requests go through an approval process where a designated approver or a group of approvers must approve the request before access is given. Google Groups lets you apply an access policy to a collection of users, enabling you to follow the policy management best practice of giving access to resources based on group membership. This approach keeps policies relevant as join, move, and leave events occur through group membership changes.

You can give and change access controls for a whole group with Google Groups, instead of giving or changing access controls one at a time for individual users or service accounts. You can also easily add members to and remove members from a Google group instead of updating an IAM policy to add or remove users.

Set up resource access using Google Groups

You can create and manage a Google group using Cloud Identity. Cloud Identity is an identity as a service (IDaaS) solution that manages users and groups. You can also configure Cloud Identity to federate identities between Google and other identity providers, such as Active Directory and Azure Active Directory. Google Groups also lets a user request membership to a group. This request is routed to group administrators who can then approve or decline that request. To learn more, see Create a group and choose group settings.

When you create and manage a Google group to give access to Google Cloud resources, make sure to consider the implications of the settings that you select. Although we recommend that you minimize the number of users who can manage the group, we recommend that you set up more than one group administrator to always have access to the group. We also recommend that you restrict group membership to users in your organization.

Implementation

In this example procedure, you create a Google group and give the viewer group access to a sample Google Cloud project. Members that you add to this group (or that you give access to upon request) are able to view the sample Google Cloud project.

Create a sample Google group

The following steps assume that you have Cloud Identity configured. To learn more, see Setting up Cloud Identity. Make sure that you have the permissions that you need to manage groups.

In the Google Cloud console, go to the Groups page.

Go to Groups
Click Create.
Fill in the details for your group.

To add members to the group, click Add member, then enter the email address for the member and choose their Google Groups role.

When you're finished, click Submit to create the group.

Group settings can only be managed within Google Groups. To configure group settings, click Manage this group in Google Groups. To select who can join the group, in the Who can join the group menu, select Organization users only.
Click Create Group.

Grant the group access to a Google Cloud project

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Open Cloud Shell:

Go to Cloud Shell
Run the following command to give the group viewer access to the project:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=group:GROUP_EMAIL --role=roles/viewer
```
Replace the following:
- GROUP_EMAIL: the email address of the group you created
- PROJECT_ID: the ID of your Google Cloud project

Test the user access request process for users in your organization

In the following procedure, you use a test user account to demonstrate the steps that users in your organization use to request access to a Google group.

Sign in to Google Groups as a non-administrative user. The group that you created in Create a sample Google group appears under All Groups. If the group doesn't appear, use search to find it.
To request access to the group, click Ask to join group.

Once access is given, the non-administrative user account that you used to make the request should be able to view the Google Cloud PROJECT_ID project that the group has Viewer access to.

Give time-bound access to Google Cloud resources

There might be situations when users in your enterprise require temporary, short-term access to Google Cloud resources. Short-term access is useful when developers need temporary access to Google Cloud resources to perform certain tasks. Short-term access also offers the following advantages:

Reducing administrative overhead.
Ensuring that the principle of least privilege and timely access is followed.

Being able to give this type of access is useful for administrators when users need access to resources in emergency situations that require quick and direct intervention. However, it can be difficult to manually track short-term access permissions and ensure that they are removed in a timely manner. IAM conditional access policies let you set temporary (expiring) access to Google Cloud resources using conditional role bindings, helping to reduce this overhead for administrators.

Use conditional role bindings and group membership expiration

You can add conditional role bindings to new or existing IAM policies to further control access to Google Cloud resources. Some examples of when you might use conditional role bindings to give a user or a group temporary access are as follows:

Access to a project that expires after a specified time.
Access to a project that recurs every month or quarter.
Access to Compute Engine instances to administer tasks such as stopping instances.

When you use Google Groups to give users access to Google Cloud resources, you can use the group membership expiration feature to set expirations for group membership using the Cloud Identity Groups API. When the time that you specify has passed, users are removed from the group automatically.

Implementation

You can use a conditional role binding to give developers temporary access to administer a specific Compute Engine instance. In this example, the role binding is set to expire on December 31, 2021.

In Cloud Shell, set the following variables:
```
export INSTANCE=create example-instance-1
export ZONE=us-west1-b
export USER=USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO
```
Replace USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO with the username of the user in your organization that you want to give temporary access to.
Create a sample Compute Engine instance:
```
gcloud compute instances create $INSTANCE \
    --zone $ZONE \
    --machine-type g1-small
```
You give temporary access to this instance to a user in your organization in the following steps.

Give the user that you selected temporary access:

gcloud compute instances add-iam-policy-binding $INSTANCE \
    --zone=$ZONE \
    --member="user:$USER" \
    --role='roles/compute.instanceAdmin.v1' \
    --condition='expression=request.time < timestamp("2022-01-01T00:00:00Z"),title=expires_end_of_2021,description=Expires at midnight on 2021-12-31'

Retain the Compute Engine instance that you create. You use this instance later in this document in Managing privileged access.

Alternatively, you can delete the example-instance-1 instance by running the following command:
```
gcloud compute instances delete $INSTANCE
```

Log lifecycle events related to identity

If you need to review IAM lifecycle events such as policy changes, service account creation, and service account assignments for auditing, Cloud Audit Logs can help. Administrators can use Cloud Audit Logs to look back at historical data for forensics and analysis. Analyzing audit logs can help you to understand access patterns and access anomalies. Audit log analysis can also be important for the following scenarios:

Analyzing permissions and access to resources during a data breach.
Analyzing production issues caused by a change in IAM policy, particularly if you want to verify which user or what process made the change.

Cloud Audit Logs stores information about the actions that users take, where the activity occurred, and when. Audit logs are classified as follows:

Admin Activity audit logs
Data Access audit logs
System Event audit logs
Policy Denied audit logs

We recommend that you use the following audit logs for identity and access related administrative logging:

Admin Activity audit logs
Policy Denied audit logs

Admin Activity audit logs store changes made to Google Cloud resources such as projects, Compute Engine instances, and service accounts. The following are examples of events that Admin Activity audit logs store:

The creation of a service account.
A change in an IAM policy.
The download of a service account key.

Policy Denied audit logs record when a user or a service account is denied access to a Google Cloud service due to a security policy violation.

Set up Cloud Audit Logs for identity lifecycle events

You can view audit logs in the Google Cloud console or query the logs using the Cloud Logging API or the command-line interface.

All audit logs have a retention period. If your enterprise needs to store audit logs for longer than the default retention period, you need to export the logs to BigQuery or other sink destinations by creating a log sink. Exporting logs to BigQuery lets you view a subset of data columns and selected data (over time or other dimensions), and do aggregate analysis.

Implementation

The following example procedure shows you how to query Google Cloud project logs to check if any of the following events have occurred:

There have been IAM policy changes.
New service accounts have been created.
New service account keys have been generated.

View changes to IAM policies

In the Google Cloud console, go to the Logging > Logs Explorer page.
On the Logs Explorer page, select an existing Google Cloud project.

Paste the following query into Query Builder:

logName="projects/<PROJECT>/logs/cloudaudit.googleapis.com%2Factivity" AND
(resource.type="project" OR resource.type="service_account") AND
resource.labels.project_id="<PROJECT>" AND
(protoPayload.methodName="SetIamPolicy" OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"
OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey")

Replace PROJECT with your Google Cloud project ID.

Click Run query.

View changes to group membership

Changes to Google group membership are tracked in Activity logs. To learn how to access these logs, see Viewing group membership change logs.

Access certification

The Policy Analyzer can be used to help your enterprise verify that users have the appropriate access rights to Google Cloud resources on a set or periodic basis. This verification is important for compliance and audit purposes. It's also useful for security personnel and auditors to review which users have access to which resource and in what capacity. The Policy Analyzer helps you to identify which identities or principals (users, service accounts, groups, and domains) have access to which Google Cloud resources across the resource hierarchy in your organization. It also helps to identify what the type of access is. Some example questions that the Policy Analyzer can help you answer are as follows:

Which users can access a service account.
Which users can read data in a BigQuery dataset that contains personally identifiable information (PII).

Policy Analyzer can be used with the following methods:

Using the Google Cloud console.
Using APIs.
Exporting IAM policies data to BigQuery for asynchronous analysis.

Use Policy Analyzer to check user access

The following example queries show the type insights that you can gain into user access with the Policy Analyzer:

What roles or permissions a principal (user, service account, group, and domain) has; for example, checking what access a former employee has to your production project.
Which resources a user has access to; for example, the access a former employee has to your production project resources.
Which principals have a certain level of access to a resource; for example, which buckets a specific user can delete in a project.

Implementation

In the following example procedure, you use the Policy Analyzer to verify the permissions that a user has.

In Cloud Shell, enable the Cloud Asset API for the project:

Enable the API
Enter the following command to find out which resources a user can access:
```
gcloud asset analyze-iam-policy --organization="YOUR_ORG_ID" \
    --identity="user:USERNAME_TO_CERTIFY"
```
Make the following replacements:
- YOUR_ORG_ID: your Google Cloud Organization ID
- USERNAME_TO_CERTIFY: the username of the user whose Google Cloud access permissions you want to verify.
Extract the IAM policy data to BigQuery. To learn more, see Writing policy analysis to BigQuery.

Manage privileged access

Some users in your organization might need privileged access to certain Google Cloud resources to perform administrative tasks. For example, these users might need to manage specific Google Cloud projects, set up project billing and budgets, or administer Compute Engine instances.

Instead of permanently granting users privileged access to resources, you can let users request just-in-time privileged access. Using just-in-time privileged access management can help you do the following:

Reduce the risk of someone accidentally modifying or deleting resources. For example, when users have privileged access only when it's needed, it helps prevent them from running scripts at other times that unintentionally affect resources that they shouldn't be able to change.
Create an audit trail that indicates why privileges were activated.
Conduct audits and reviews for analyzing past activity.

Alternatively, you can grant privileged access to a service account and allow users to impersonate the service account.

Give privileged access to users

Broadly, management of privileged access to enterprise users in Google Cloud can be summarized as follows:

Giving users in the enterprise the ability to request privileged access.
Reviewing Cloud Audit Logs to analyze privileged access requests and access patterns. Administrators can review privileged access patterns and detect anomalies using these logs. We recommend that enterprises consider exporting these logs to persist as necessary and appropriate for audit purposes.
Ensuring that privileged access either expires automatically or is reviewed periodically.

Enable 2-step verification (also called multi-factor authentication) for all users that have privileged access to resources. You can also create fine-grained, attribute-based access control by using Access Context Manager, which enforces an extra layer of security when privileged access is used. For example, you can have an access level that specifies that users must be on the corporate network when using privileged access to resources.

Implementation

In this example procedure, you (as an administrator) create a Google group for privileged access to Compute Engine instances. You create a service account in Google Cloud that is given access to administer Compute Engine instances. You associate the group with the service account so that group members are able to impersonate the service account for the period that they are given membership to the privileged group.

Create a Google group for privileged access

As a Google Cloud administrator, select or create a Google Cloud project.

Go to Manage Resources
Enable billing for your project. Enable Billing
Follow the steps in Give users the ability to request access to resources to create a new Google group.

Name the group as follows: elevated-compute-access

Create a Google Cloud service account

In Cloud Shell, enable the IAM Service Account Credentials API for the project that you created in Create a Google group for privileged access.

Enable the APIs

Set the following variables:

export PROJECT_ID=$DEVSHELL_PROJECT_ID
export PRIV_SERVICE_ACCOUNT_NAME=elevated-compute-access
export DELEGATE_GROUP=GROUP_EMAIL_ADDRESS

Replace GROUP_EMAIL_ADDRESS with the full name of the Google group that you created.

Create the service account:

gcloud IAMservice-accounts create $PRIV_SERVICE_ACCOUNT_NAME \
    --description="Elevated compute access" \
    --display-name="Elevated compute access"

Give the service account the compute administrator role:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/compute.admin"

Give the Google group you created Service Usage consumer access for your project:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="group:$DELEGATE_GROUP" \
    --role="roles/serviceusage.serviceUsageConsumer"
```
This permission lets the Google group members impersonate the service account that you created.

Give the Google group the ability to impersonate the service account you created:

gcloud IAMservice-accounts add-iam-policy-binding
$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com --member="group
:$DELEGATE_GROUP" --role="roles/iam.serviceAccountTokenCreator"

Skip this step if you created and retained a sample Compute Engine instance for the procedure in Give time-bound access to Google Cloud resources. You can use the sample instance to run the steps in this example.

Alternatively, use the following command to create a sample Compute Engine instance:
```
gcloud compute instances create example-instance-1 \
    --zone us-west1-b \
    --machine-type g1-small
```
You use the instances in this example to validate that users who are given membership to the privileged group can access the instance.

Enable audit logs

Administrators in your enterprise can enable Cloud Audit Logs to make sure that privileged access is logged and available for review and analysis. The procedure in this section shows you how to enable audit logging.

Get the current IAM policies for the project:

gcloud projects get-iam-policy $PROJECT_ID > /tmp/policy.yaml

Modify the policy file to enable data access logs for Compute Engine API:

cat <<EOF >> /tmp/policy.yaml
auditConfigs:
- auditLogConfigs:
 - logType: ADMIN_READ
 - logType: DATA_READ
 - logType: DATA_WRITE
 service: compute.googleapis.com
EOF

Set the new policy:

gcloud projects set-iam-policy $PROJECT_ID /tmp/policy.yaml

Test impersonation with the non-administrative user account

You can use the non-administrative user account to test the setup by requesting membership to the group and impersonating the service account once membership is given.

The procedure in this section shows you how enterprise users can request privileged access to Google Cloud resources. In this example procedure, the Google Cloud resources are the Compute Engine instances for a Google Cloud project. To demonstrate how users in your organization can impersonate a service account once they are given membership to the group, you request membership to relevant Google groups.

Sign in to Google groups with the non-administrative user account and request membership to the elevated-compute-access group.
Use the same account to sign in to Google Cloud. You should have access to the group once an administrator approves the request. In this example procedure, it is assumed that your Group Membership request is approved.

Note: Group administrators should give expiring membership to users as appropriate to specific business requirements in your enterprise. They must follow the guidance outlined in the Cloud Identity API documentation. In this document, it's assumed that the user account that you use to set up the Google group in Create a Google group for privileged access is the group administrator.
In Cloud Shell, run the following command to set the default project:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with the project ID that you created earlier in the Create a Google group for privileged access section.
Attempt to list the Compute Engine instances in this project:
```
gcloud compute instances list
```
You see an error message informing you that your Google Cloud user doesn't have the permission to access Compute Engine resources.
Run the following command:
```
gcloud compute instances list
--impersonate-service-account=elevated-compute-access@$PROJECT_ID.iam.gserviceaccount.com
```
This command lists the Compute Engine instances in the project by impersonating the service account that you gained access to when you were given membership to the elevated-compute-access Google group.

You see the example-instance-1 Compute Engine instance that you created with your administrator account.

Check audit logs

As a Google Cloud administrator, you can access and review the generated audit logs.

Sign in to the Google Cloud console with a user account that has administrative privileges to access audit logs.
In Cloud Logging, enter the following query to review data access logs:
```
logName="projects/<PROJECT_ID>/logs/cloudaudit.googleapis.com%2Fdata_access"
AND
protoPayload.authenticationInfo.principalEmail="elevated-compute-access@PROJECT_ID.iam.gserviceaccount.com"
```
Replace PROJECT_ID with your project ID and then run the query.

This query shows you which user in the Google group impersonated the service account to access the Compute Engine instance. It also shows you other relevant details such as when the service account was impersonated and the details of the request headers.
Review the audit log payload, specifically the protoPayload.authenticationInfo object in the payload. The username of the user who impersonated the service account is logged as the value of the principalEmail key of the firstPartyPrincipal object.
As an administrator, you can also review event-threat findings in the Security Command Center dashboard. To learn more about Security Command Center, see Using Event Threat Detection.

What's next

Review best practices for managing identity and access.
Discover how Policy Intelligence offers smart access control for your Google Cloud resources.
Read about how you can troubleshoot policy and access problems on Google Cloud
Read about best practices for creating and managing Google Cloud service accounts.
For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.