Google FAQ and Troubleshooting

1. In the Console, navigate to Settings > Integrations.
2. Click on the three dots menu next to the organization, and click Edit.
3. Click Next to navigate to the last step in the wizard (Scopes).
4. Select Exclude specific folders and projects and then select the relevant folder or project.
5. Click Finish. It will be removed from the Console the next time Tenable syncs data in your environment.

In order to see all relevant role bindings, Tenable needs permissions to be granted on the parent-level scope (organization). Without this ability, Tenable cannot provide critical security information for GCP resources, such as effective permissions. Even though role bindings are granted on the level of the organization, Tenable cannot access any other organization-level data unless the organization itself, or specific projects within it, are onboarded to Tenable.

After you delete a project in GCP, it takes 30 days until the project is fully deleted. After this 30 day period, Tenable will offboard the project automatically from the system. Since Google Cloud allows you to revert the deletion during this time period, Tenable doesn't delete the data from the system until after 30 days, allowing you to restore the project in GCP if you wish. For more information, refer to the relevant Google documentation{target=_blank}.

It's possible that some members of your organization independently created Google accounts using the domain of your organization. Such accounts are considered unmanaged user accounts by Google, and are categorized by Tenable as external. Refer to Google documentation{target=_blank} for more information.

Terraform is only supported for GCP organizations.

Although the name of this role might be misleading, it effectively allows Tenable to impersonate{target=_blank} (or "assume") the service account to interact with your environment via queries.

This is the safest method Tenable has found to connect to your GCP environment as a third party.

The alternative, which is sometimes used by other vendors, is to create user-managed access keys. This requires manual rotation, and can be compromised. The benefit of using impersonation here is that it reduces your risk exposure by not having static credentials associated with Tenable's service account. See Service Account Impersonation vs. Service Account Key.

According to GCP documentation{target=_blank}, service account impersonation is more secure than using a service account key, because impersonation requires a prior authenticated identity, and the credentials that are created do not persist. In comparison, authenticating with a service account key requires no prior authentication, and the persistent key is a high risk credential if exposed.

Tenable needs to access certain Google APIs in your environment that require the super administrator user. These are needed for identity and other general cloud security capabilities. Here is a partial list of APIs:

• https://developers.google.com/admin-sdk/reference-overview
• https://cloud.google.com/identity/docs/apis

However, the actual permissions granted to Tenable are restricted to the OAuth scopes granted when you add your workspace. These permissions are all read-only. So, although Tenable needs super administrator permissions to access the required APIs, in practice, only read-only permissions are actually granted, thus limiting risk.

Tenable needs an email address, because the only way to query objects in Google Workspace is by using domain-wide delegation and user impersonation, which requires a user email address. For more information about how service accounts should access Google Workspace, refer to Google documentation{target=_blank}. Mailbox is not required for this user.

Domain-wide delegation is a Google Workspace mechanism used to grant applications with domain-wide access to relevant user data. This delegation of authority is done using service accounts with OAuth 2.0. The access granted via this delegation is what allows Tenable to gather and provide information fundamental to understanding your GCP assets, since Google Workspace is inherently connected to GCP.

Without this access, Tenable would be unable to:

• Map Google Workspace users to the GCP resources they use.
• Map Google Workspace users to groups, since GCP permissions can be granted to groups.
• Build user/group permission graphs
• Identify users with strong Google Workspace permissions who can therefore escalate their privileges in GCP (e.g., Super Administrators).

Domain-wide delegation lets Tenable impersonate any Google Workspace user, including administrators. Despite the fact that, technically speaking, it might appear as if Tenable has super administrator permissions, this is not actually the case in practice: Tenable does not have any administrator permissions within Google Workspace. The actual permissions granted to Tenable are restricted to the specific OAuth scopes defined during the configuration of domain-wide delegation: These permissions only grant Tenable read access to Google Workspace.

For more information refer to the relevant Google Workspace documentation: https://developers.google.com/admin-sdk/directory/v1/guides/delegation

This role contains permissions to manage API access for the Tenable service account, which is needed by Tenable to:

• Query some of the services that you're currently using in your environment.
• Automatically support new GCP services as they are released.

Although the name of this role might be misleading, it effectively allows Tenable to enable APIs needed to collect configuration data from your GCP environment. Without this ability, Tenable wouldn't be able to perform the functions mentioned above.

Since quotas are managed in GCP{target=_blank} per project, and Tenable's service account belongs to a single project, the permissions contained in this role are limited in scope. Unless you explicitly enable API access for a service in a different project, Tenable will not have access to it. Even though Tenable's service account can query new services from the dedicated project that you added during the onboarding process, it cannot alter quotas in your environment.

AI Exposure currently maps all services and permissions in your GCP environment programmatically, meaning that as soon as a new GCP service is released, you can view it in Tenable, along with its underlying permissions.