GCP Model Engine Support

[arniechops]

Pull Request Summary

What is this PR changing? Why is this change being made? Any caveats you'd like to highlight? Link any relevant documents, links, or screenshots here if applicable.

Test Plan and Usage Guide

How did you validate that your PR works correctly? How do you run or demo the code? Provide enough detail so a reviewer can reasonably reproduce the testing procedure. Paste example command line invocations if applicable.

Greptile Summary

This PR adds GCP Workload Identity Federation (WIF) support to the model-engine Helm chart by injecting the iam.gke.io/gcp-service-account annotation onto the main and inference Kubernetes Service Accounts when GCP values are configured. The changes follow the same conditional annotation pattern already used for Azure workload identity.

Key points:

• service_account.yaml: Adds iam.gke.io/gcp-service-account annotation when gcp.iam_service_account is set. The annotation is gated inside {{- with $annotations }}, meaning it will be silently omitted if serviceAccount.annotations is empty — potentially breaking WIF without any rendering error.
• service_account_inference.yaml: Adds the same annotation with a clean fallback (inference_service_account → iam_service_account). This file is structurally safer because its top-level guard already requires annotations to be non-empty.
• No imagePullSecrets equivalent is added for GCP (consistent with GCP's Workload Identity approach for image pulls).
• No documentation, values schema, or sample values were updated to reflect the new gcp value shape, which may make the feature harder to discover.

Confidence Score: 3/5

• This PR is mostly safe but has a silent failure risk in the main service account template that could break GCP Workload Identity when no base annotations are configured.
• The inference service account change is clean and safe. The main service account change follows the same pattern as the existing Azure implementation but has a meaningful silent-failure risk: if serviceAccount.annotations is empty, the GCP WIF annotation is dropped without any error. Since GCP WIF is the entire purpose of this PR, a deployment with no base annotations would silently produce a non-functional workload identity binding. The PR also lacks documentation or sample values for the new gcp value shape.
• Pay close attention to charts/model-engine/templates/service_account.yaml — the GCP annotation gating logic needs review.

Important Files Changed

Filename	Overview
charts/model-engine/templates/service_account.yaml	Adds GCP Workload Identity annotation (iam.gke.io/gcp-service-account) for the main service account. The annotation is gated inside {{- with $annotations }}, so it will be silently dropped if serviceAccount.annotations is empty/unset — breaking GCP WIF for deployments that don't configure base annotations.
charts/model-engine/templates/service_account_inference.yaml	Adds GCP Workload Identity annotation for the inference service account, with a correct fallback from inference_service_account to iam_service_account. The top-level guard already requires serviceAccountAnnotations to be set, so the with $annotations gate doesn't create a silent failure risk here.

Sequence Diagram

sequenceDiagram
    participant HelmValues as Helm Values
    participant SATemplate as service_account.yaml
    participant InfSATemplate as service_account_inference.yaml
    participant K8s as Kubernetes API

    HelmValues->>SATemplate: $.Values.gcp.iam_service_account set?
    alt gcp.iam_service_account set AND serviceAccount.annotations non-empty
        SATemplate->>K8s: ServiceAccount with iam.gke.io/gcp-service-account annotation
    else serviceAccount.annotations empty (silent failure)
        SATemplate->>K8s: ServiceAccount WITHOUT iam.gke.io/gcp-service-account annotation
    end

    HelmValues->>InfSATemplate: serviceTemplate.serviceAccountAnnotations set?
    alt annotations set (required by top-level guard)
        alt gcp.inference_service_account set
            InfSATemplate->>K8s: Inference SA with inference_service_account annotation
        else gcp.iam_service_account set (fallback)
            InfSATemplate->>K8s: Inference SA with iam_service_account annotation
        end
    else annotations not set
        InfSATemplate->>K8s: Template skipped entirely (no SA created)
    end

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: charts/model-engine/templates/service_account.yaml
Line: 19-23

Comment:
**GCP WIF annotation silently dropped when no base annotations configured**

The new GCP `iam.gke.io/gcp-service-account` annotation is nested inside `{{- with $annotations }}`, where `$annotations` comes from `.Values.serviceAccount.annotations`. If a deployer configures `gcp.iam_service_account` but leaves `serviceAccount.annotations` empty (or unset), `$annotations` will be falsy and the entire `annotations:` block — including the GCP workload identity annotation — will be skipped silently.

Workload Identity Federation requires this annotation on the Kubernetes Service Account to function. Without it, pods will fail to authenticate to GCP services without any obvious error in the Helm rendering output.

The inference service account in `service_account_inference.yaml` avoids this problem structurally because the top-level `{{- if and ... (.Values.serviceTemplate.serviceAccountAnnotations) ...}}` guard requires annotations to be set before the template renders at all. The main service account has no such guard.

Consider moving the GCP block outside of the `{{- with $annotations }}` block (similar to how `imagePullSecrets` is handled at the top level), or adding a Helm `required` validation that fails early if `gcp.iam_service_account` is set but `serviceAccount.annotations` is empty:

```yaml
  {{- with $annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
    {{- if $.Values.azure }}
    azure.workload.identity/client-id: {{ $.Values.azure.client_id }}
    {{- end }}
  {{- end }}
  {{- if $.Values.gcp }}
  {{- if $.Values.gcp.iam_service_account }}
  annotations:
    iam.gke.io/gcp-service-account: {{ $.Values.gcp.iam_service_account }}
  {{- end }}
  {{- end }}
```

Note: a cleaner structural fix would merge the two annotations blocks, but the above illustrates the concern.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "feat(chart): Add GCP..."}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

GCP WIF annotation silently dropped when no base annotations configured

The new GCP iam.gke.io/gcp-service-account annotation is nested inside {{- with $annotations }}, where $annotations comes from .Values.serviceAccount.annotations. If a deployer configures gcp.iam_service_account but leaves serviceAccount.annotations empty (or unset), $annotations will be falsy and the entire annotations: block — including the GCP workload identity annotation — will be skipped silently.

Workload Identity Federation requires this annotation on the Kubernetes Service Account to function. Without it, pods will fail to authenticate to GCP services without any obvious error in the Helm rendering output.

The inference service account in service_account_inference.yaml avoids this problem structurally because the top-level {{- if and ... (.Values.serviceTemplate.serviceAccountAnnotations) ...}} guard requires annotations to be set before the template renders at all. The main service account has no such guard.

Consider moving the GCP block outside of the {{- with $annotations }} block (similar to how imagePullSecrets is handled at the top level), or adding a Helm required validation that fails early if gcp.iam_service_account is set but serviceAccount.annotations is empty:

  {{- with $annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
    {{- if $.Values.azure }}
    azure.workload.identity/client-id: {{ $.Values.azure.client_id }}
    {{- end }}
  {{- end }}
  {{- if $.Values.gcp }}
  {{- if $.Values.gcp.iam_service_account }}
  annotations:
    iam.gke.io/gcp-service-account: {{ $.Values.gcp.iam_service_account }}
  {{- end }}
  {{- end }}

Note: a cleaner structural fix would merge the two annotations blocks, but the above illustrates the concern.

Prompt To Fix With AI

This is a comment left during a code review.
Path: charts/model-engine/templates/service_account.yaml
Line: 19-23

Comment:
**GCP WIF annotation silently dropped when no base annotations configured**

The new GCP `iam.gke.io/gcp-service-account` annotation is nested inside `{{- with $annotations }}`, where `$annotations` comes from `.Values.serviceAccount.annotations`. If a deployer configures `gcp.iam_service_account` but leaves `serviceAccount.annotations` empty (or unset), `$annotations` will be falsy and the entire `annotations:` block — including the GCP workload identity annotation — will be skipped silently.

Workload Identity Federation requires this annotation on the Kubernetes Service Account to function. Without it, pods will fail to authenticate to GCP services without any obvious error in the Helm rendering output.

The inference service account in `service_account_inference.yaml` avoids this problem structurally because the top-level `{{- if and ... (.Values.serviceTemplate.serviceAccountAnnotations) ...}}` guard requires annotations to be set before the template renders at all. The main service account has no such guard.

Consider moving the GCP block outside of the `{{- with $annotations }}` block (similar to how `imagePullSecrets` is handled at the top level), or adding a Helm `required` validation that fails early if `gcp.iam_service_account` is set but `serviceAccount.annotations` is empty:

```yaml
  {{- with $annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
    {{- if $.Values.azure }}
    azure.workload.identity/client-id: {{ $.Values.azure.client_id }}
    {{- end }}
  {{- end }}
  {{- if $.Values.gcp }}
  {{- if $.Values.gcp.iam_service_account }}
  annotations:
    iam.gke.io/gcp-service-account: {{ $.Values.gcp.iam_service_account }}
  {{- end }}
  {{- end }}
```

Note: a cleaner structural fix would merge the two annotations blocks, but the above illustrates the concern.

How can I resolve this? If you propose a fix, please make it concise.