> For the complete documentation index, see [llms.txt](https://docs.ox.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ox.security/ox-integrations/3rd-party-integrations/cloud-security/gcp-and-gke-1/gcp-workload-identity-keyless/entire-google-cloud-organization.md). # Entire Google Cloud Organization ## About connecting an entire Google Cloud organization You can connect an entire Google Cloud organization to OX using Workload Identity Federation. OX uses one read-only service account to access projects across the organization without creating or maintaining a long-lived service account key. Select a project to host the service account and Workload Identity Pool. The scanning reach comes from IAM roles granted at the organization level. First, configure the required resources and permissions in Google Cloud. Then, use the generated values to complete the connection in OX. ## Prerequisites Make sure that you have: * The Google Cloud CLI (`gcloud`) installed and configured, or access to Cloud Shell. * Permissions to create a service account in the host project. * `roles/resourcemanager.organizationAdmin` on the organization to grant the required roles at the organization level. * `roles/serviceusage.serviceUsageAdmin` to enable the required APIs in the projects in the organization. * `roles/iam.workloadIdentityPoolAdmin` must be a required API, or Owner on the host project in order to create Workload Identity pools in the host project. * Access to the GCP connector in OX. > Run each command on a single line. Line continuations pasted into Cloud Shell split at the backslash. ### Step 1: Configure Google Cloud To configure an entire Google Cloud organization for OX: 1. Sign in to Google Cloud and list the available organizations and projects. ```bash gcloud auth login # skip in Cloud Shell gcloud organizations list --format="table(displayName,name)" gcloud projects list --format="table(projectId,name)" ``` 2. Set the variables for the organization, host project, and Workload Identity configuration. Pick any project to hold the service account and the Workload Identity Pool. Scanning reach comes from the organization bindings configured later in this procedure. ```bash ORG_ID= PROJECT= gcloud config set project "$PROJECT" PROJECT_NUMBER=$(gcloud projects describe "$PROJECT" --format="value(projectNumber)") POOL_ID=ox-pool PROVIDER_ID=ox-oidc ``` 3. Enable the APIs required to create the service account. ```bash [First API enablement command — remainder not visible in screenshot] [Second API enablement command — remainder not visible in screenshot] ``` 4. Create the read-only service account and set `SA` to its email. One service account serves every project, and every organization. To reuse an existing one, set `SA` to its email and `PROJECT` to the segment between `@` and `.iam.gserviceaccount.com`. ```bash gcloud iam service-accounts create ox-readonly --display-name="OX read-only" # skip when reusing SA=ox-readonly@$PROJECT.iam.gserviceaccount.com ``` 5. Grant the read-only roles at the organization level. Roles bind once at the organization and every project inherits them. Granting these needs `roles/resourcemanager.organizationAdmin` on the organization, and enabling the APIs in every project needs `roles/serviceusage.serviceUsageAdmin`. See Roles granted to OX for what each covers. ```bash ROLES="roles/viewer roles/iam.securityReviewer roles/storage.objectViewer roles/accessapproval.viewer roles/accesscontextmanager.policyReader roles/discoveryengine.viewer roles/firebaserules.viewer roles/firebase.viewer roles/healthcare.datasetViewer" for R in $ROLES; do gcloud organizations add-iam-policy-binding "$ORG_ID" --member="serviceAccount:$SA" --role="$R"; done ``` 6. Verify the organization IAM policy. ```bash [Organization IAM policy verification command — remainder not visible in screenshot] ``` 7. In OX, open **Connectors > GCP > Workload Identity (Keyless)** and copy the **Issuer URI**. 8. Return to your Google Cloud shell and set `ISSUER_URI` to the Issuer URI that you copied from OX. ```bash ISSUER_URI= ``` 9. Create the Workload Identity Pool in the host project. The pool lives in the host project and covers the whole organization. ```bash gcloud iam workload-identity-pools create "$POOL_ID" --location=global --display-name="OX" ``` 10. Create the Workload Identity provider. ```bash [Workload Identity provider command — remainder not visible in screenshot] ``` 11. Allow identities that authenticated through the pool to obtain credentials for the service account. This grant is what lets the token OX presents become the identity of the service account. ```bash [Service account Workload Identity User binding command — remainder not visible in screenshot] ``` 12. Set the two batches of APIs that must be enabled in every project. API enablement is set per project. `gcloud services enable` accepts up to 20 APIs per call, so the list runs in two batches. ```bash B1="[First API list — remainder not visible in screenshot]" B2="[Second API list — remainder not visible in screenshot]" ``` 13. Enable the required APIs in every project in the organization. The loop prints one line per project. It runs one project at a time, so a large organization can take a while. It is safe to re-run. ```bash [Project API enablement loop — remainder not visible in screenshot] ``` Note: Projects created later pick up the organization roles by inheritance, while API enablement is per-project state that inherits nothing. Re-run this step as new projects appear, or add the API list to your project-creation template. 14. Add the output values to the connector's page. ```bash echo "//iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/providers/$PROVIDER_ID" echo "$SA" ``` > **Note:** Projects created later pick up the organization roles by inheritance, while API enablement is per-project state that inherits nothing. Re-run this step as new projects appear, or add the API list to your project-creation template. ## Step 2: Complete the connection in OX 1. In OX, go to **Connectors > GCP**.
2. Select **Workload Identity (Keyless)**. 3. Enter the connection details: | Field | Description | | ------------------------------------------ | ------------------------------------------------------------------------------------------------ | | Workload Identity Pool Provider (audience) | Enter the Workload Identity Pool Provider value generated during the Google Cloud configuration. | | Service account to impersonate | Enter the service account email generated during the Google Cloud configuration. | | Connection Name | Enter a name that identifies the organization in OX. | 4. Select **Verify Connectivity**. 5. After OX verifies the connection, select **Connect**. ## Step 3: Connect GKE You can connect GKE clusters in projects in the connected organization to OX. GKE uses the credentials configured for the GCP connector. OX reads each GKE cluster through its Kubernetes API from the following IP addresses: * `108.128.213.11` * `34.247.61.212` If a cluster restricts control-plane access using a private endpoint or authorized networks, add both OX IP addresses to the allowlist. **To connect GKE clusters:** 1. Add `108.128.213.11` to the allowlist if access to the cluster control plane is restricted. 2. Add `34.247.61.212` to the allowlist if access to the cluster control plane is restricted. 3. In OX, go to **Connectors > GKE**.
4. Select **Connect**. 5. Select the clusters that you want to connect. 6. Save the connection. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ox.security/ox-integrations/3rd-party-integrations/cloud-security/gcp-and-gke-1/gcp-workload-identity-keyless/entire-google-cloud-organization.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.