Validate token endpoints of user-supplied external_account credentials

[akkaur]

Issue

The GCP plugins accept a service account credential as inline JSON or a file path and load it with GoogleCredentials.fromStream, which accepts any credential type the auth library supports, including external_account (workload identity federation).

An external_account configuration tells the auth library where to obtain a subject token (credential_source) and where to send it: the subject token is sent to token_url and the resulting access token to service_account_impersonation_url. When such a configuration comes from user input, these endpoints must be validated; otherwise the configuration could direct tokens to an arbitrary endpoint. See Google's guidance on validating credential configurations from external sources: https://cloud.google.com/docs/authentication/client-libraries#validate_other_credential_configurations

Fix

This change adds that validation in GCPUtils.loadServiceAccountCredentials, the single method all plugin credential paths (validation, connection test, deploy and runtime) go through. For configurations of type external_account:

• token_url must be exactly https://sts.googleapis.com/v1/token
• service_account_impersonation_url, if present, must be exactly https://iamcredentials.googleapis.com/v1/projects/-
/serviceAccounts/:generateAccessToken

With both endpoints pinned to Google's documented values, whatever the configuration reads can only be sent to Google. Non-conforming configurations are rejected with a validation error naming the field.

The JSON is parsed with the same parser GoogleCredentials.fromStream uses, so the validation sees exactly the document the library will act on.

[gemini-code-assist]

Code Review

This pull request introduces validation for external account credentials in GCPUtils to prevent potential token theft and exfiltration attacks by ensuring that token and impersonation URLs match expected Google endpoints. It also adds comprehensive unit tests in GCPUtilsTest to verify these security constraints. The review feedback highlights a potential NullPointerException when parsing empty or null JSON configurations and suggests simplifying the test code by replacing a custom stream-reading helper with Guava's ByteStreams.toByteArray.

[gemini-code-assist]

If the parsed JSON is empty or null, JsonObjectParser.parseAndClose can return null. Calling json.get("type") directly without a null check would then result in a NullPointerException. Please add a null check for json before accessing its properties.

Suggested change

	GenericJson json = new JsonObjectParser(GsonFactory.getDefaultInstance())
	.parseAndClose(new ByteArrayInputStream(credentialBytes), StandardCharsets.UTF_8, GenericJson.class);
	if (!EXTERNAL_ACCOUNT_TYPE.equals(json.get("type"))) {
	return;
	}
	GenericJson json = new JsonObjectParser(GsonFactory.getDefaultInstance())
	.parseAndClose(new ByteArrayInputStream(credentialBytes), StandardCharsets.UTF_8, GenericJson.class);
	if (json == null || !EXTERNAL_ACCOUNT_TYPE.equals(json.get("type"))) {
	return;
	}

[gemini-code-assist]

Instead of using a custom readAll helper method, you can use Guava's ByteStreams.toByteArray(InputStream) which is already available on the classpath and used in the main source code. This simplifies the test code and avoids custom stream copying logic.

Suggested change

	try (InputStream is = exchange.getRequestBody()) {
	attackerBody.set(new String(readAll(is), StandardCharsets.UTF_8));
	}
	try (InputStream is = exchange.getRequestBody()) {
	attackerBody.set(new String(com.google.common.io.ByteStreams.toByteArray(is), StandardCharsets.UTF_8));
	}

[gemini-code-assist]

This custom readAll helper method can be completely removed if you use Guava's ByteStreams.toByteArray(InputStream) instead.