diff --git a/applications/configure/secure-cloud-access.mdx b/applications/configure/secure-cloud-access.mdx
index 8f6ab4c..b578573 100644
--- a/applications/configure/secure-cloud-access.mdx
+++ b/applications/configure/secure-cloud-access.mdx
@@ -113,9 +113,11 @@ See [Connections in porter.yaml](/applications/configuration-as-code/services/co
 
 ## GCP
 
-Workload identity support for GCP is **in development**. The equivalent flow on GKE — binding a Porter service to a Google service account via [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) — is not yet generally available.
+Porter uses [GKE Workload Identity](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) to let a service's Kubernetes service account impersonate a GCP IAM service account. Your application code can then use Google's default credential chain (e.g. `google.auth.default()` in Python, `google.NewDefaultCredentials` in Go) and tokens for the GCP service account are resolved automatically — no JSON key files mounted into the pod.
 
-If you'd like this enabled for your project, reach out to Porter support and we'll work with you to get early access.
+Workload Identity is enabled per node pool. Toggle **Enable Workload Identity** on the GKE node group your service runs on before attaching a GCP service account — see [Enabling Workload Identity on a node group](#enabling-workload-identity-on-a-node-group) below.
+
+Full self-serve UI for binding a Porter service to a Google service account is still rolling out. If you'd like this enabled for your project, reach out to Porter support and we'll work with you to get early access.
 
 ### Enabling Workload Identity on a node group
 
diff --git a/cloud-accounts/node-groups.mdx b/cloud-accounts/node-groups.mdx
index 50d1df3..1d72803 100644
--- a/cloud-accounts/node-groups.mdx
+++ b/cloud-accounts/node-groups.mdx
@@ -130,6 +130,34 @@ Create custom node groups for specialized workloads like GPU processing, high-me
 
 ---
 
+## GKE Workload Identity (GCP)
+
+For node groups on GKE clusters, you can opt individual node pools into [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity). When enabled, the GKE metadata server runs on the node pool so pods scheduled there can impersonate a GCP IAM service account at runtime — without mounting service account keys.
+
+Enable this on any node group whose workloads need to call GCP APIs (for example, BigQuery, Cloud Storage, or Pub/Sub) using a GCP service account connection.
+
+<Steps>
+  <Step title="Edit the node group">
+    From your Porter dashboard, navigate to **Infrastructure** → your GKE cluster, and expand the node group you want to enable Workload Identity on.
+  </Step>
+  <Step title="Toggle Enable Workload Identity">
+    Switch on **Enable Workload Identity**. The toggle appears only for GCP clusters.
+  </Step>
+  <Step title="Update">
+    Scroll to the bottom and click **Update**. GKE applies the change to the node pool. Existing pods on the pool restart as nodes are rolled.
+  </Step>
+</Steps>
+
+<Warning>
+Enabling Workload Identity on an existing node group can interrupt workloads that rely on the node's default Compute Engine service account. See [Enabling Workload Identity on a node group](/applications/configure/secure-cloud-access#enabling-workload-identity-on-a-node-group) for the full impact and rollout guidance.
+</Warning>
+
+<Info>
+Leave Workload Identity disabled on node groups whose workloads don't need GCP API access. The metadata server adds a small amount of overhead per node and exposes additional metadata endpoints to pods on the pool.
+</Info>
+
+---
+
 ## Assigning Workloads to Node Groups
 
 Once your custom node group is created, assign applications to run on it: