---
title: "Workload Identity Federation"
slug: "workload-identity-federation"
updated: 2026-07-09T04:41:11Z
published: 2026-07-09T04:41:11Z
canonical: "docs.dataloop.ai/workload-identity-federation"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataloop.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workload Identity Federation

DDOE supports secure, keyless access to cloud resources through **Workload Identity Federation (WIF)**—a modern and recommended alternative to using long‑lived credentials such as service account keys or access keys.

With WIF, DDOE services such as pipelines, automations, and serverless functions can dynamically assume identities at runtime to securely access resources across cloud providers (including AWS, Azure, and GCP), without embedding sensitive credentials within the platform.

WIF eliminates the need for static secrets by enabling authentication through trusted identity providers (such as Azure AD, AWS IAM, or other OIDC providers). The process works as follows:

- A trust relationship is established between DDOE and an external identity provider.
- DDOE requests a short‑lived authentication token from the identity provider.
- The target cloud platform validates the identity and issues temporary credentials.
- DDOE uses these credentials to securely access cloud resources (such as storage services).

DDOE supports secure, keyless access to Google Cloud Platform (GCP) resources through **Workload Identity Federation (WIF)** — a modern and recommended alternative to using long-lived service account keys.

With WIF, DDOE services such as pipelines, automations, and serverless functions can **assume a Google IAM identity** at runtime, enabling access to GCP services like **Cloud Storage**, without embedding sensitive credentials in the platform.

To set up a **Workload Identity Federation (WIF)** integration between **Google Cloud Platform (GCP)** and the **DDOE platform**, you'll need to complete steps on **both GCP and DDOE**, and collect specific credentials during the process.

---

## Setting Up WIF in GCP

### Create WIF in GCP

#### 1: Set up a Workload Identity Pool

1. Go to the **Google Cloud Console → IAM & Admin → Workload Identity Federation**.
2. Click **Create Pool**:
  1. **Name**: e.g., `DDOE-wif-pool`
  2. **ID**: auto-fills based on name
  3. **Description**: Optional
  4. **Access Type**: Choose `Federated`
  5. Click **Continue**, then **Create**

#### 2: Create a Workload Identity Provider

1. After creating the pool, click into it and go to the **"Providers"** tab.
2. Click **"Add Provider"**:

Leave JWKS URI empty if not used; Google will fetch from the issuer URI.
  - **Provider Type**: `OIDC`
  - **Name**: e.g., `DDOE-provider`
  - **Issuer URI**: This is DDOE’s OIDC issuer (ask DDOE support if not documented; usually looks like `https://dataloop.ai/oauth2` or similar)
  - **Allowed Audiences**: Provide a unique `aud` value (can be the DDOE client ID or a known audience used by DDOE)

#### 3: Map Attribute Conditions

Configure attribute mapping:

```json
jsonCopyEdit{
  "google.subject": "assertion.sub"
}
```

(Optional) You can add attribute conditions if you want to restrict access (e.g., allow only certain email domains).

#### 4: Create or Reuse a GCP Service Account

```bash
bashCopyEditgcloud iam service-accounts create dataloop-access
```

Then allow the **Workload Identity Pool** to impersonate this service account:

```bash
bashCopyEditgcloud iam service-accounts add-iam-policy-binding dataloop-access@your-project.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/<project-number>/locations/global/workloadIdentityPools/dataloop-wif-pool/attribute.subject/*"
```

---

### **Prepare Credentials for DDOE**

#### 1: **Client ID and Client Secret**

> [!NOTE]
> These refer to an OAuth 2.0 client created in GCP.

To generate:

1. Go to **Google Cloud Console → APIs & Services → Credentials**.
2. Click **"Create Credentials" → "OAuth client ID"**
  - **Application Type**: Web application
  - **Name**: e.g., `DDOE Integration`
  - **Authorized redirect URIs**: Add the DDOE redirect URI (provided in the DDOE Integration UI)
3. Once created, copy:
  - **Client ID:** The **Client ID** is the Application (App Registration) ID.
  - **Client Secret:** The **Client Secret** is generated under the app registration.
  - **Azure Scope**: The **Scope** defines what permissions DDOE is requesting.

These go into DDOE when creating the integration.

#### 2: **Credential Configuration JSON File**

Instead of a service account key, you will create a JSON **credential configuration file** for the workload identity.

You can generate this file using the CLI:

```bash
bashCopyEditgcloud iam workload-identity-pools create-cred-config \
  "projects/<project-number>/locations/global/workloadIdentityPools/dataloop-wif-pool/providers/dataloop-provider" \
  --service-account="dataloop-access@your-project.iam.gserviceaccount.com" \
  --output-file=credentials.json
```

This will generate a `credentials.json` that contains all necessary information for DDOE to assume the service account identity via WIF.

---

### **Create the GCP Integration in DDOE**

1. Log in to the DDOE platform.
2. From the left-side panel, select **Integrations**.
3. Click **Create Integration → Create Storage Integration**. A pop-up window is displayed on the right-side.
4. **Integration Name**: Enter a **Name** for the integration.
5. **Provider**: Choose **GCP** from the list.
6. **Integration Type**: Select the [**Workload**](https://portal.document360.io/53f32fe9-1937-4652-8526-90c1bc78d3f8/document/1-3-8/view/90082176-60c6-4533-8809-ebc7d14b0ad4) **Identity Federation** from the list.
7. **Client ID**: From OAuth
8. **Client Secret**: From OAuth
9. **Import JSON file**: Click to upload the generated `credentials.json` file.
10. Click **Create Integration**. A confirmation message is displayed.

Once the integration is created, you can use it in:

- **Drivers** (e.g., GCS buckets)
- **Services** (e.g., inference tasks)
- **Pipelines** (e.g., prediction nodes)