Revoke access to a Google Cloud project

Stay organized with collections Save and categorize content based on your preferences.

This document describes best practices, scenarios, and procedures for revoking a user's access to a Google Cloud project. Because each business has different policies and workloads, we recommend that you use this document to come up with your own policies and procedures that let you revoke access consistently and in a timely manner.

When an employee leaves your company, your engagement with a contractor ends, or a collaborator moves on to other projects, there are a few things you should do to revoke unneeded access to your cloud resources.

Some of these processes are optional. You should determine which of these steps to execute depending on your security needs, products in use, and trust in the person whose access is being revoked.

Best practices for setting up your project

You can improve your project's ability to efficiently revoke user access by making thoughtful choices at setup time.

Federate user accounts with your existing identity provider

When you federate user accounts with your existing identity provider, make sure that you propagate user suspension and deletion events. With propagation, when you suspend or remove a user account from your identity provider, the user also loses access to Google Cloud resources.

For more information, see Best practices for federating Google Cloud with an external identity provider.

For more identity-related best practices, see Best practices for planning accounts and organizations.

For information about Workforce Identity Federation, see Workforce Identity Federation.

Consider using Google Groups to manage access to project resources

Google Groups let you organize users based on their team membership, access requirements, or other criteria. After you create Google Groups, you can assign access to Google Cloud projects and resources based on group membership. When a user moves to another team or job function, you can move the user account to another group, which automatically removes the access that was granted by allow policies to the previous group.

Using Google Groups isn't appropriate in all circumstances. For example, you shouldn't use groups that are based only on your business' organization structure to manage access. For best practices on group usage, see Best practices for using Google Groups.

For more information, see Managing groups in the Google Cloud console and Create a group in your organization

Use OS Login

Use OS Login instead of metadata-based SSH keys so that the user's authorized keys are linked to their Google identity. When you remove a user account, the authorized keys and access to VMs are revoked automatically. For more information, see Use OS Login to ensure continuous access evaluation against IAM policies.

For instructions, see Set up OS Login.

Restrict access from external user accounts

Don't grant external users access to the project because you can't control the lifecycle for these user accounts. To restrict external users, use the iam.allowedPolicyMemberDomains list constraint.

For instructions, see Restricting identities by domain.

Use authentication proxies with databases

Authentication proxies let you connect the lifecycle of database credentials to the lifecycle of a Google identity. When you suspend or delete a user account in Cloud Identity or Google Workspace, access to databases is automatically revoked.

For more information, see Cloud SQL Auth proxy and AlloyDB for PostgreSQL Auth proxy.

Prepare for credential rotation

Design your projects and resources to allow for non-disruptive rotation of project-level credentials. These are secrets tied to the project itself, such as service account keys, OAuth client secrets, and application-specific secrets like database root passwords. For more information, see Handle compromised Google Cloud credentials.

Restrict API keys

When creating and managing API keys, restrict the set of web sites, IP addresses, and apps that can use them. A user account with roles like Viewer or API Keys Admin can see your project's API keys, so any unrestricted keys must be rotated or deleted in order to revoke billing access. For more information, see Secure an API key.

Monitor access permissions

Carefully tracking access helps mitigate against potential access abuse. You can use IAM role recommender to track role usage to help enforce the least privilege principle. In addition, Security Command Center's Cloud Infrastructure Entitlement Management (CIEM) capabilities let you manage which identities have access to which resources in your deployments and mitigate potential vulnerabilities that result from misconfigurations.

Use uniform bucket-level access for Cloud Storage

Uniform bucket-level access lets you use IAM alone to manage permissions for your Cloud Storage buckets. Use uniform bucket-level access along with other access control options to refine who can access the content in your buckets.

Additional best practices

In addition to the best practices described in this document, review the following best practices:

• Best practices for working with service accounts
• Decide the security for your Google Cloud landing zone
• Verify every access attempt explicitly

Scenarios for revoking access to Google Cloud projects

If you implemented the best practices listed in Best practices for setting up your project, the following table summarizes how you can revoke access.

Revoke access

If you've made good choices in project setup, the following processes will be an efficient way to revoke a person's access.

To determine what resources a person has access to, use Policy Analyzer. For instructions, see Analyze IAM policies.

Delete the user account from your identity provider

If the user is leaving your organization, and you've federated Cloud Identity or Google Workspace with your identity provider, with automatic user provisioning, access revocation can happen automatically.

For information about deleting Workforce Identity Federation users, see Delete Workforce Identity Federation users and their data.

Move the account to another group

If the user is changing roles, remove the user account from their current Google Groups. If you've federated Cloud Identity or Google Workspace with your identity provider to manage group membership, access revocation can happen automatically.

For more information, see Viewing and editing group details.

Remove the user account from IAM allow policies

To remove a user account from project-level allow policies, do the following:

1. In the Google Cloud console, go to the IAM permissions page.

   IAM permissions

2. Select the project that you want to remove a user account from.

3. Click the checkbox next to the row that contains the user account you want removed from the member list, then click Remove.

To verify other locations where the allow policy can be set, including folders, organization, or individual resources, see Verify permissions were removed.

Rotate project credentials

Rotate service account keys

If you use service account keys to authenticate to a service account, you must rotate the keys. In addition, consider if the person might have had access to service account keys somewhere outside of Google Cloud tools, such as your source code repository or application configurations.

1. In the Google Cloud console, go to the API credentials page.

   API credentials

2. Click the name of the service account that you want to modify.

3. Under the Key tab, click Add Key.

4. Click Create new key.

5. Choose the Key type you want to create. In most situations, JSON is recommended, but P12 is available for backwards compatibility with code that depends on it.

6. Click Create. A file containing the new key will be automatically downloaded through your browser. Deploy this key to any applications that need it.

7. After confirming the new key works as expected, return to the credentials page and delete the old key associated with that service account.

Rotate OAuth client ID secrets

OAuth client ID secrets don't provide any direct access to your project. However, if an attacker knows the OAuth client ID secret, they can spoof your application and request access to your users' Google Accounts from a malicious application.

You might need to rotate OAuth client ID secrets if the person whose access is being revoked ever had access to the secret, including in your source code repository, application configurations, or through IAM roles.

1. In the Google Cloud console, go to the API credentials page.

   API credentials

2. Click the name of the OAuth 2.0 client ID that you want to modify.

3. On the Client ID page, click Reset secret.

4. Click Reset in the confirmation dialog to immediately revoke the old secret and set a new one. Note that any active users will need to reauthenticate upon their next request.

5. Deploy the new secret to any applications that need it.

Rotate API keys

API keys don't provide access to your project or your users' data, but they control who Google bills for API requests. A user account with roles like Viewer or API Keys Admin can see your project's API keys. If you have any unrestricted keys, you need to delete or regenerate them when revoking someone's access to your project.

1. In the Google Cloud console, go to the API credentials page.

   API credentials

2. Click the name of the API key that you want to modify.

3. Click Regenerate key.

4. A dialog will display the newly created key. Deploy this key to any applications using the key that you want to replace.

5. After confirming that your applications are working as expected with the new key, return to the credentials page and delete the old unrestricted key.

Revoke access to VMs

If the person whose access you are revoking doesn't have login access to any of your project VMs, you can skip this step.

1. Remove all project-level SSH keys that the person had access to.

2. On each VM where the person had SSH access, remove any instance-level keys.

3. Remove the person's account from any VMs they had login access to.

4. Check for suspicious applications the person might have installed to provide backdoor access to the VM. If you are uncertain about the security of any code running on the VM, recreate it and redeploy the applications you need from source.

5. Verify that the VM firewall settings haven't been changed from your planned or expected configuration.

6. If you create new VMs from custom base images, verify that the base images haven't been modified in a way that would compromise the security of new VMs.

Revoke access to databases

If your project doesn't use Cloud SQL or AlloyDB for PostgreSQL resources, you can skip this step.

To revoke access to a Cloud SQL database, complete the following:

1. In the Google Cloud console, go to the SQL instances page.

   SQL instances

2. Click the instance ID of the database you want to revoke access to.

3. In the left menu, click Connections.

4. Confirm that the list of IP addresses under Authorized networks and list of apps under App Engine authorization match what you expect. If the person whose access you're trying to revoke has access to networks or applications listed here, they can access this database.

5. In the left menu, click Users.

6. Delete or change the password for any user accounts that the person had access to. Be sure to update any applications that depend on those user accounts.

To revoke access to an AlloyDB for PostgreSQL database, see Remove an IAM user or service account from a cluster.

Redeploy App Engine

By default, App Engine apps have access to a service account that is an editor on the associated project. App Engine request handlers can do things like create new VMs and read or modify data in Cloud Storage. Someone with the ability to deploy code to App Engine could use this service account to open a backdoor into your project. If you're concerned about the code integrity of your deployed apps, you might want to redeploy them (including any modules) with a known-good image from your version control system.

Verify permissions were removed

You can verify permissions at the organization level, the project level, or using Policy Analyzer.

To find resources that a particular user might have access to at the organization level, use the search-all-iam-policies method in Google Cloud CLI. For example, to determine whether a user has access to your resources, run:

gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'

Where:

• ORGANIZATION_ID is your organization number.
• IDENTITY is the user's identity, such as an email address.

To verify permissions on a project, see Permissions a principal has on a project.

To verify permissions using Policy Analyzer, see Determine which resources a principal can access.

What's next

• See Handle compromised Google Cloud credentials.

• Learn more Best practices for mitigating compromised OAuth tokens for Google Cloud CLI.

• Create a deny policy to specify which permissions the user can't access any longer.