GCP Native Authentication Method

[dangtony98]

Description 📣

This PR adds the new GCP native authentication method to Identities consisting of GCP ID Token Auth and GCE IAM Auth.

With this method, GCP resources avoid secret zero by not needing to store an additional token to authenticate with Infisical. Instead, they can use credentials/metadata already present in GCP to prove their identity to Infisical — this works by relaying an identity / signed JWT token through Infisical to be verified by the public key returned from the GCP API; if successful and certain allow conditions are met, then the entity is considered authenticated and an access token granting access to the Infisical API is returned.

Workflow for GCP ID Token Auth:

1. The operator sets up the GCP GCE authentication method in Infisical. As part of the setup, they specify what Allowed Service Accounts, Allowed Projects, and Allowed Zones can be trusted.
2. The operator programs the client application in GCP to send an ID Token to Infisical at the /api/v1/auth/gcp-auth/login endpoint also containing the identityId that they are authenticating as (in practice this would likely be done via SDK or other client but it can also be done manually).
3. Infisical verifies the ID Token against Google's public OAuth2 certificates.
4. If successful (meaning the identity token is valid), then Infisical checks the returned the token properties against the Allowed Service Accounts, Allowed Projects, and Allowed Zones defined in step 1. Note that Allowed Projects and Allowed Zones will only be checked for GCE instances where that metadata is returned as part of the ID Token response from GCP.
5. If successful, then Infisical returns an identity access token (similar to in Universal Auth).

Workflow for GCP IAM Auth:

1. The operator sets up the GCP IAM authentication method in Infisical. As part of the setup, they specify what Allowed Service Accounts.
2. The operator programs the client application in GCP to send a signed JWT token to Infisical at the /api/v1/auth/gcp-auth/login endpoint also containing the identityId that they are authenticating as (in practice this would likely be done via SDK or other client but it can also be done manually).
3. Infisical verifies the signed JWT token using the public key obtained from https://www.googleapis.com/service_accounts/v1/metadata/x509/ endpoint.
4. If successful (meaning the JWT was indeed signed by an allowed service account being the client), then Infisical checks the returned the JWT token properties against the Allowed Service Accounts defined in step 1.
5. If successful, then Infisical returns an identity access token (similar to in Universal Auth).

Note 1: The GCP authentication method will require additional engineering work for clients like Infisical Agent and SDKs to support it.

Note 2: The GCP authentication method requires a network connection from Infisical to GCP to verify the signed service account JWT token.

Type ✨

• Bug fix
• New feature
• Breaking change
• Documentation

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[maidul98]

how come we don't do a check to make sure that the user enters at least one filter? From reading your PR description it sounds like Google will allow say if the the identity auth token is valid which means that with no filters anyone can send any valid token and get access. Let me know if i misunderstood something

[dangtony98]

That's correct. If no filters are specified, then it will allow any GCP entity with a valid ID token to authenticate as the corresponding identity in Infisical; in the current iteration it would be on the operator for configuring it this way.

The configuration is intentionally left optional for all the filters so users can define whichever combination that they wish (for GCP IAM Auth it would be necessary in practice to specify allowed service accounts but for GCP ID Token Auth it wouldn't); we can alternatively enforce more granularly that IF the type is IAM Auth then allowed service accounts must be non-empty.

[maidul98]

I think we should make it so that at least one filter is applied or at least mention in the docs that when you don't apply a filter, anyone can access your identity. I have a feeling that people might misunderstand so would be good to remind them just in case. Maybe you can do this in a separate commit in the docs for now?

[maidul98]

Left one comment for clarification