From 3906d54609c302730bdcf4c36aa7053b1503f519 Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Wed, 24 Jun 2026 23:41:49 +0000 Subject: [PATCH] docs: note WI toggle now available on system and monitoring node groups --- applications/configure/secure-cloud-access.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/applications/configure/secure-cloud-access.mdx b/applications/configure/secure-cloud-access.mdx index 1bbe31c..8ebe00e 100644 --- a/applications/configure/secure-cloud-access.mdx +++ b/applications/configure/secure-cloud-access.mdx @@ -160,11 +160,13 @@ See [Connections in porter.yaml](/applications/configuration-as-code/services/co When you turn on Workload Identity for a node group, GKE deploys a metadata server on those nodes that intercepts calls to the GCE metadata endpoint. Once enabled, pods can no longer reach the node's default Compute Engine service account through that endpoint — they obtain Google credentials through a Workload Identity–bound Kubernetes service account instead. +Workload Identity can be enabled per node group on application, user, system, and monitoring pools. Toggling it on the system or monitoring pool is an operator-only action and only needs to happen if a workload that lives on those pools needs to authenticate to GCP through a service account connection. + Enabling Workload Identity can interrupt workloads that rely on the node's default service account. If any pod on the node group authenticates to Google APIs using the default node service account (for example, through the GCE metadata endpoint or the default credential chain), it will lose access until it's reconfigured to use a Workload Identity–bound Kubernetes service account. -Before enabling it on a node group that already runs production traffic, confirm that none of its workloads depend on the default node service account. If you're not sure, create a new node group with Workload Identity enabled and [schedule your workloads](/cloud-accounts/node-groups#assigning-workloads-to-node-groups) on it to test before changing an existing node group. +Before enabling it on a node group that already runs production traffic, confirm that none of its workloads depend on the default node service account. If you're not sure, create a new node group with Workload Identity enabled and [schedule your workloads](/cloud-accounts/node-groups#assigning-workloads-to-node-groups) on it to test before changing an existing node group. Porter only shows the warning banner in the dashboard once the toggle has been flipped on, so a pool that's still off won't surface a notice — the warning is meant as a confirmation of the pending change. ---