Skip to content

Draft feature docs: WI toggle on system and monitoring node groups #385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mintlify wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Draft feature docs: WI toggle on system and monitoring node groups #385

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion applications/configure/secure-cloud-access.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

<Warning>
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.
</Warning>

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.

---

Expand Down