Revoke access to a Google Cloud project

This document describes best practices, scenarios, and procedures for revoking a user's access to a Google Cloud project. Use this document to come up with policies and procedures that let you revoke access consistently and in a timely manner.

A critical time in the life of your Google Cloud resources is when you need to remove someone’s access to them. 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 thoroughly revoke unneeded access to your 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, you can synchronize the status of your user accounts. When you remove a user account from your identity provider, the user identity in Cloud Identity is also deleted, and the user no longer gets access to Google Cloud resources through your allow policies.

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.

Use Google Groups to manage access to project resources

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

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 you can link your users' Linux accounts to their Google identities. When you remove a user account, the keys are revoked automatically.

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 Cloud SQL Auth proxy when connecting to Cloud SQL

Cloud SQL Auth proxy lets you connect workloads to Cloud SQL based on IAM permissions, instead of IP-based access control such as authorized networks. The Cloud SQL Auth proxy validates connections by using credentials for a user or service account and by wrapping the connection in a SSL/TLS layer that's authorized for your Cloud SQL instance. It is a more secure method of connecting than using self-managed SSL/TLS certificates or authorized networks. It also lets you remove access to Cloud SQL when you revoke permissions to the user account, or delete the user account completely.

Limit access to VMs

Virtual machines, like those used by Compute Engine and Google Kubernetes Engine, are large potential attack surfaces. If someone has ever had access to a VM, especially root or Administrator access, it’s extremely difficult to guarantee that they haven’t modified the VM and left a backdoor to allow themselves future access. Limit VM access to those people who have a clear and specific need for it.

By default, project editors and owners have administrative access to all VMs in the project. Remove this default access and use the principle of least privilege for VM access.

Before you grant VM login access, think about what tasks require access, and determine whether there are other ways to meet those needs if possible. For example, instead of giving VM login access to every developer in order to deploy code, consider using tools like Chef, Puppet, and Salt to manage your deployments.

Prepare for credential rotation

Design your projects and resources to allow for easy and non-disruptive rotation of project-level credentials. These are secrets tied to the project itself, like service account keys, OAuth client secrets, and application-specific secrets, like database root passwords. For more information, see Handling 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.

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
• Manage identity and access

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.

Scenario	Revoking access options
An employee leaves your company.	If you set up federation between Cloud Identity or Google Workspace with automatic user provisioning, access revocation can happen automatically. If you didn't follow best practices and you granted external user identities access to your resources, then you must manually remove the identities from your projects and resources.
An employee changes their job function.	You remove the employee from the team group.
A contract engagement ends.	If you set up federation between Cloud Identity or Google Workspace with automatic user provisioning, access revocation can happen automatically. If you didn't follow best practices and you granted external user identities access to your resources, then you must manually remove the identities from your projects and resources.
An account was compromised.	For instructions, see Handling compromised Google Cloud credentials.

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.

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.

Remove the user account from project membership

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.

Rotate project credentials

Note: If you have applications and services depending on project-level secrets, be sure to update them after rotating 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.

Note: Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keys whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by Best practices for managing service account keys. If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see Managing secure-by-default organization resources.

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.

Note: These steps break the OAuth clients until you deploy the new client ID secret.

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 wish 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.

Note: If someone has ever had root access to a VM, it's difficult to guarantee that their access has been terminated by removing their associated user account. That person might be able to log in as a different user, use personal public keys to access other accounts, or run processes as other users. The most secure procedure is to recreate VMs from a known good image.

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 Cloud SQL databases

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

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.

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

In Google Cloud CLI, run the search-all-iam-policies method to find any resources that a particular user account might have access to. 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.

What's next

• See Handling compromised Google Cloud credentials.

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

• Read the Google Cloud security overview.