Workload identity federation in GCP - Step-by-Step Execution

Process Flow - Workload identity federation

External Workload Requests Token

↓

Federation Config Checks

↓

Validate External Identity

↓

Issue GCP Access Token

↓

Workload Accesses GCP Resources

↓

Access Granted

The external workload requests a token, which is validated and exchanged for a GCP access token, allowing secure access to GCP resources.

Execution Sample

GCP

1. Configure workload identity pool
2. Create provider for external identity
3. Grant roles to pool
4. External workload requests token
5. Token exchanged for GCP access token

This sequence shows how an external workload uses identity federation to get a GCP access token.

Process Table

Step	Action	Input	Output	Notes
1	Create workload identity pool	Pool name, description	Pool created	Pool acts as trust boundary
2	Create identity provider	Provider config (OIDC, AWS, etc.)	Provider linked to pool	Defines external identities
3	Grant IAM roles	Pool members	Roles assigned	Defines permissions for federated identities
4	External workload requests token	External identity token	Federation token request	Workload presents external token
5	Validate external token	Federation token request	Validated identity	Checks token signature and claims
6	Issue GCP access token	Validated identity	GCP access token	Token allows resource access
7	Workload accesses GCP resource	GCP access token	Access granted or denied	Based on assigned roles
8	End	N/A	N/A	Process complete

💡 Process stops after workload receives access or is denied based on token validation and IAM roles.

Status Tracker

Variable	Start	After Step 4	After Step 6	Final
Workload Identity Token	None	External token received	Validated token	Used to get access token
GCP Access Token	None	None	Issued	Used for resource access
Access Permission	None	None	None	Granted or denied based on roles

Key Moments - 3 Insights

Why does the external workload need to present its own token before getting a GCP token?

Because GCP needs to verify the external identity before issuing an access token, as shown in step 4 and 5 of the execution_table.

What happens if the external token is invalid or expired?

The validation in step 5 fails, so no GCP access token is issued, and access is denied, stopping the process early.

How does GCP know what permissions to grant the federated workload?

Permissions come from IAM roles assigned to the workload identity pool members, configured in step 3.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the external token validated?

A Step 3

B Step 6

C Step 5

D Step 7

💡 Hint

Check the 'Action' column for token validation in the execution_table.

According to variable_tracker, what is the state of the GCP Access Token after Step 4?

A None

B Validated

C Issued

D Used for resource access

💡 Hint

Look at the 'GCP Access Token' row and the 'After Step 4' column in variable_tracker.

If the IAM roles were not assigned in Step 3, what would happen at Step 7?

A Access would be granted anyway

B Access would be denied

C Token validation would fail

D External token would not be accepted

💡 Hint

Refer to the 'Notes' in Step 3 and Step 7 in execution_table about roles and access.

Concept Snapshot

Workload Identity Federation lets external workloads access GCP securely.
1. Create identity pool and provider.
2. Assign IAM roles to pool members.
3. External workload presents token.
4. GCP validates and issues access token.
5. Workload uses token to access resources.

Full Transcript

Workload identity federation allows external workloads to access Google Cloud resources without using long-lived service account keys. The process starts by creating a workload identity pool and linking an external identity provider. IAM roles are assigned to the pool members to define permissions. When an external workload wants access, it presents its own identity token. GCP validates this token and, if valid, issues a short-lived access token. The workload then uses this token to access GCP resources according to the assigned permissions. This method improves security by avoiding key distribution and enabling fine-grained access control.