Skip to main content

Google Cloud

Visualize Google Cloud resources, map Google Cloud users to employees, and monitor visibility and governance of the environment through queries and alerts.

Installation​

info

To use this integration, JupiterOne needs access to a Google Cloud service account with the correct API services enabled. You can provide a service account key file, or use Workload Identity Federation so that no long-lived key is created. In addition, you must have permission in JupiterOne to install new integrations.

Overview​

The Google Cloud integration requires three main configuration steps:

  1. Enable Google Cloud service APIs for the services you want to ingest
  2. Create a service account with appropriate permissions
  3. Configure the integration in JupiterOne with either the service account key or Workload Identity Federation

Google Cloud Configuration​

Google Cloud has most API services disabled by default. When a Google Cloud service API is disabled, the JupiterOne integration will not ingest the data from that API.

tip

You only need to enable the APIs for the services you want JupiterOne to ingest. If a service is not used in your Google Cloud environment, you can skip enabling its API.

See the Authorization tab for the full list of required APIs and permissions per ingestion step.

info

Required APIs: The following APIs must always be enabled for the integration to function: cloudasset.googleapis.com, cloudresourcemanager.googleapis.com, iam.googleapis.com, and serviceusage.googleapis.com. All other APIs are optional and should only be enabled if you want to ingest data from those specific services.

Enabling Google Cloud Service APIs​

Google Cloud service APIs can be enabled from the Google Cloud Console API Library or using the gcloud CLI. See the Authorization tab for the complete list of APIs used by this integration.

Creating Google Cloud project service account​

We must assign the correct permissions to the newly created service account for the integration to be run. We recommend using the following roles managed by Google Cloud:

Instead of using the Google Cloud managed roles listed above, you can create a custom IAM role with only the specific permissions required by the JupiterOne integration. See the Authorization tab for the complete list of permissions per ingestion step. See the Google Cloud custom role documentation for information on how custom roles can be configured and assigned.

You may also create a service account using the gcloud CLI.

Generate a service account key​

note

To create a service account key, your Google Cloud user must hold the Service Account Key Admin (roles/iam.serviceAccountKeyAdmin) role on the project or service account. Ask your administrator to grant it if you do not have it.

In the Google Cloud console, go to IAM & Admin > Service Accounts, select the service account you created, open the Keys tab, and choose Add key > Create new key > JSON. See the Google Cloud service account key documentation for more information on how to create a service account key for the service account that you would like to ingest data from.

You may also create a service account key using the gcloud CLI.

Keyless authentication with Workload Identity Federation​

Instead of a service account key, JupiterOne can authenticate with Workload Identity Federation. JupiterOne runs on AWS. For each run, it assumes a dedicated JupiterOne AWS role and uses a session named after your JupiterOne account ID. Google Cloud exchanges that AWS identity for short-lived credentials and impersonates your service account. No key is created or stored.

JupiterOne presents this AWS identity:

arn:aws:sts::<JUPITERONE_AWS_ACCOUNT_ID>:assumed-role/JupiterIntegrationGoogleCloudWif/<YOUR_JUPITERONE_ACCOUNT_ID>
JupiterOne region<JUPITERONE_AWS_ACCOUNT_ID>
US612791702201
EU043196788006

<YOUR_JUPITERONE_ACCOUNT_ID> is the ID of your JupiterOne account, exactly as JupiterOne stores it. For other JupiterOne environments, or if you are unsure of either value, contact JupiterOne Support.

caution

The attribute condition and the service account binding in the steps below are both required. They restrict the federation to your JupiterOne account's session. Without them, other workloads in the JupiterOne AWS account could use your provider.

  1. Create the service account and grant it roles, as described in Creating Google Cloud project service account. Do not create a key.

  2. In the project that will host the workload identity pool, enable the IAM (iam.googleapis.com), Security Token Service (sts.googleapis.com) and Service Account Credentials (iamcredentials.googleapis.com) APIs.

  3. Create a workload identity pool:

    gcloud iam workload-identity-pools create jupiterone \
      --project="POOL_PROJECT_ID" \
      --location="global" \
      --display-name="JupiterOne"

  4. Create an AWS provider in the pool. It trusts the JupiterOne AWS account, maps google.subject to the assumed-role ARN, and accepts only your JupiterOne session:

    gcloud iam workload-identity-pools providers create-aws jupiterone-aws \
      --project="POOL_PROJECT_ID" \
      --location="global" \
      --workload-identity-pool="jupiterone" \
      --account-id="<JUPITERONE_AWS_ACCOUNT_ID>" \
      --attribute-mapping="google.subject=assertion.arn" \
      --attribute-condition="assertion.arn == 'arn:aws:sts::<JUPITERONE_AWS_ACCOUNT_ID>:assumed-role/JupiterIntegrationGoogleCloudWif/<YOUR_JUPITERONE_ACCOUNT_ID>'"

  5. Allow that exact identity to impersonate the service account. POOL_PROJECT_NUMBER is the numeric project number of the pool project, not its ID:

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
      --role="roles/iam.workloadIdentityUser" \
      --member="principal://iam.googleapis.com/projects/POOL_PROJECT_NUMBER/locations/global/workloadIdentityPools/jupiterone/subject/arn:aws:sts::<JUPITERONE_AWS_ACCOUNT_ID>:assumed-role/JupiterIntegrationGoogleCloudWif/<YOUR_JUPITERONE_ACCOUNT_ID>"

    Do not grant the role to the whole pool (principalSet://.../*).

  6. In JupiterOne, choose the Workload Identity Federation (keyless) authentication method and enter:

    • Workload Identity Pool Provider: the provider's full resource name, for example //iam.googleapis.com/projects/POOL_PROJECT_NUMBER/locations/global/workloadIdentityPools/jupiterone/providers/jupiterone-aws. You can print it with gcloud iam workload-identity-pools providers describe jupiterone-aws --project="POOL_PROJECT_ID" --location="global" --workload-identity-pool="jupiterone" --format="value(name)". Add the //iam.googleapis.com/ prefix to the result.
    • Service Account Email: the email of the service account from step 1.
    • Service Account Project ID: the ID of the project the service account belongs to.

Workload Identity Federation also works with Configure Organization Projects. Child instances inherit the same provider and service account.

JupiterOne + Google Cloud Organization​

Given the correct permissions, JupiterOne has the ability to automatically discover each project under a Google Cloud organization and configure integration instances for each of the projects.

Setup​

  1. Select one Google Cloud project to configure a service account for JupiterOne.

  2. Create the service account without a role. Copy the email address of the new service account (e.g. my-sa@my-j1-project.iam.gserviceaccount.com).

  3. Generate and copy a new service account key, or set up Workload Identity Federation for the service account instead.

  4. Enable service APIs in both the "main" project and each "child" project that you'd like JupiterOne to access.

    Important: The following APIs must be enabled in the "main" project:

    • cloudasset.googleapis.com (Cloud Asset)
    • cloudresourcemanager.googleapis.com (Cloud Resource Manager)
    • iam.googleapis.com (Identity and Access Management)
    • serviceusage.googleapis.com (Service Usage)

    For child projects: Enable the service APIs for the specific services you want to ingest from each project. Refer to the API table in the earlier section for the complete list of supported services.

  5. Switch to the organization that you'd like to create individual integration instances for each project

  6. Create a new custom role with the following permissions:

resourcemanager.folders.get resourcemanager.folders.list resourcemanager.organizations.get resourcemanager.projects.get resourcemanager.projects.list serviceusage.services.list resourcemanager.organizations.getIamPolicy cloudasset.assets.searchAllIamPolicies

The integration will also try to ingest organization policy for "storage.publicAccessPrevention" to precisely calculate storage buckets public access, and Access Approval settings for enforcing manual approval of privileged operations (CIS 2.15), it is therefore recommended that the following permissions are also included in the custom role above:

orgpolicy.policy.get accessapproval.settings.get accessapproval.requests.get

The integration will calculate if a storage bucket is public or not based on the following conditions:

  • Public to internet means one or more bucket-level permissions grant access to allUsers or allAuthenticatedUsers.
  • Not public means the bucket's policy controls all objects uniformly, and no permissions have been granted to allUsers or allAuthenticatedUsers.
  • Subject to object ACLs means fine-grained, object-level access control lists (ACLs) are enabled. Objects may be public if they grant access to allUsers or allAuthenticatedUsers.

  1. Navigate to the Cloud Resource Manager for that organization and add a new member to the organization. The new member email address is the email address of the service account that was created earlier. Select the new organization role that was created above, as well as the Google Cloud managed role "Security Reviewer" (roles/iam.securityReviewer) or an alternative JupiterOne custom role that you've created.

  2. Navigate to the JupiterOne Google Cloud integration configuration page to begin configuring the "main" integration instance.

Use the generated service account key as the value for the "Service Account Key File" field, or choose the Workload Identity Federation (keyless) authentication method and enter its values.

note

The "Polling Interval" that is selected for the "main" integration instances will be the same polling interval that is used for each of the child integration instances.

  1. Select the "Configure Organization Projects" checkbox.
  2. Enter the numerical value of the Google Cloud organization into the "Organization ID" text field (e.g. "1234567890").
  3. Click CREATE CONFIGURATION.

Depending on how many projects exist under a Google Cloud organization, the auto-configuration process may take a few minutes to complete. When the process has been completed, you will see your new integration instances on the JupiterOne Google Cloud integration list page.

Configuration in JupiterOne​

To install the Google Cloud integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Google Cloud. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • Account Name by which you want to identify this Google Cloud account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when Add AccountName Tag is enabled.
  • Description that will assist your team to identify the integration instance.
  • Polling Interval that you feel is sufficient for your monitoring needs. You can leave this as DISABLED and manually execute the integration.
  • An authentication method:
  • Add any tags you want to use to simplify data management and queries.

Project ID of the Google Cloud project (e.g. abc-123) (optional): The project ID to target for data ingestion. Defaults to the project ID specified in the service account key file, or to the Service Account Project ID when you use Workload Identity Federation.

Select Configure Organization Projects if you want JupiterOne to auto-configure all projects in your organization. JupiterOne applies the configuration to all other projects that do not have the optional j1-integration: SKIP tag applied to the project in your infrastructure-as-code. Do not use the optional project ID if you want to use this feature.

When Configure Organization Projects is enabled, these additional options become available:

  • Auto-delete Removed Projects: When enabled, automatically deletes integration instances for projects that are deleted or removed from your organization. Disabled by default.
  • Auto-delete Child Integrations: When enabled, automatically deletes child project instances when this parent organization instance is deleted. Enabled by default.
  • Propagate Data Source Overrides: When enabled, project instances use the same data sources as this parent instance. New project instances start with them, and on each run the data source settings of existing project instances are replaced with the parent's. A data source you disable on the parent is disabled on every project instance, and its data is removed from them. An existing integration for a project in your organization that the parent takes over is synced from the following run. Project instances that belong to another parent with Configure Organization Projects enabled are left to that parent; turn that setting off on a parent you no longer use so another parent can take over its projects. Disabled by default; when disabled, data sources you change on the parent are not applied to project instances that already exist, and turning it off leaves project instances with their last synced data sources.

Folder Filter (optional): A numerical folder ID. When set, JupiterOne ingests only projects in the specified folder and its subfolders. When Configure Organization Projects is also enabled, JupiterOne auto-configures only projects within this folder.

Click Create after all values are provided to finalize the integration.

Data Volume Configuration​

Data Filtering Options​

FieldDescriptionDefault
Compute Instance Metadata FieldsComma-separated metadata field keys to ingest from Compute Engine instances. For example: key1,key2. Leave blank to ingest no custom metadata fields.Empty

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.