> For the complete documentation index, see [llms.txt](https://docs.cortex.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.io/ingesting-data-into-cortex/integrations/google/using-the-integration-for-google-cloud-platform.md).

# Using the integration for Google Cloud Platform

{% hint style="info" %}
Cortex connects to many third-party vendors whose system interfaces frequently change. As a result, integration behavior or configuration steps may shift without notice. If you encounter unexpected issues, check with your system administrator or refer to the vendor's documentation for the most current information. Additionally, integration sync times vary and are subject to scheduling overrides and timing variance.
{% endhint %}

This article explains how to use the integration for GCP. For configuration instructions, see [Configuring the integration for Google Cloud Platform](/ingesting-data-into-cortex/integrations/google.md). For instructions on connecting GCP to entities, see [Connecting entities to Google Cloud Platform](/ingesting-data-into-cortex/integrations/google/connecting-entities-to-google-cloud-platform.md).

## Viewing Google Cloud Observability data in entity pages

After connecting SLOs, Cortex surfaces Google Cloud Observability data directly on entity details pages:

* An entity's overview page shows a summary of its SLOs.
* Select **Monitoring > Google** in an entity's sidebar for more detail, including the SLO name, targets, status, current value, and the time range it's calculated over. For example, a time listed as "7 days ago" means the SLO covers the range from 7 days ago to now.

## Creating Scorecard rules and writing CQL queries with the GCP integration

With the Google integration, you can create Scorecard rules and write CQL queries based on GCP details, Google Cloud Observability SLOs, and Google teams.

See more examples in the [CQL Explorer](https://app.getcortexapp.com/admin/cql-explorer) in Cortex.

<details>

<summary>GCP details</summary>

Get the GCP details for the entity.

**Definition** - `gcp.details()`

**Examples**

A Scorecard might include a rule to verify that an entity has GCP details:

```
gcp.details() != null
```

You might include a rule to check whether any labels on the GCP recourse are titled `origin`:

```
jq(gcp.details(), ".resources[0].labels | any(\"origin\")")
```

</details>

<details>

<summary>SLOs</summary>

SLOs associated with the entity via ID or tags. You can use this data to check whether an entity has SLOs associated with it, and if those SLOs are passing.

**Definition** - `slos: List<SLO>`

**Example**

In a Scorecard, you can use this expression to make sure an entity is passing its SLOs:

```
slos().all((slo) => slo.passing) == true
```

Use this expression to make sure latency Service Level Indicator (SLI) value is above 99.99%:

```
slos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0
```

</details>

**Ownership CQL**

<details>

<summary>All ownership details</summary>

A special built-in type that supports a null check or a count check, used to enforce ownership of entities.

**Definition -** `ownership: Ownership | Null`

**Example**

An initial level in a security Scorecard might include a rule to ensure an entity has at least one team as an owner:

```
ownership.teams().length > 0
```

</details>

<details>

<summary>All owner details</summary>

List of owners, including team members and individual users, for each entity.

**Definition** - `ownership.allOwners()`

**Example**

The Scorecard might include a rule to ensure that entity owners all have an email set:

```
ownership.allOwners().all((member) => member.email != null)
```

</details>

<details>

<summary>Team details</summary>

List of teams for each entity.

**Definition** - `ownership.teams(): List<Team>`

**Example**

The Scorecard might include a rule to ensure that an entity owners all have a description and are not archived:

```
ownership.teams().all(team => team.description != null and team.isArchived == false)
```

</details>

## Viewing GCP integration logs <a href="#still-need-help" id="still-need-help"></a>

{% hint style="info" %}
This feature is available in Cortex cloud.
{% endhint %}

While viewing an integration's settings page, select the **Logs** tab to view error logs from the last 7 days. You can filter the logs list by configuration and by operation (for example, you could filter to view errors surfaced only via Scorecards).

<div align="left" data-with-frame="true"><figure><img src="/files/x8JmoPqXZTJ7YHeFJpOA" alt="The &#x27;Logs&#x27; tab on an integration&#x27;s settings page shows error information over the past 7 days." width="563"><figcaption></figcaption></figure></div>

Click into a row to get more information, including time stamp, status code, full error, and request path.

## Troubleshooting and FAQ <a href="#still-need-help" id="still-need-help"></a>

See frequently asked questions below.

**The GCP integration only supports a single service account. Is there a workaround?**

By default, GCP service accounts are restricted to the project they were created in. If other projects don’t explicitly allow that service account to access their resources, Cortex can’t collect data from them. To work around this, you can configure a [principal service account](https://docs.cloud.google.com/iam/docs/principals-overview) and associate it with multiple projects in GCP. Once the service account is linked to other projects, Cortex can use that service account to pull data from multiple GCP projects.

After creating a service account that is linked to a project, open your second project in GCP and go to **IAM & Admin > IAM >** Click **+Add**. Using the service account ID that you already created, add a principal to the project. Repeat these steps for each project.