Can not deploy gen2 trigger cloud functions with custom service account

[sconix]

Environment info

firebase-tools: 13.3.1

Platform: Debian

Test case

export const automatedBackupFromFirestoreV2 = onSchedule(
  {
    region: 'europe-west1',
    schedule: 'every 168 hours',
    serviceAccount: 'compute-engine-default@*****.iam.gserviceaccount.com',
  },
  async () => {});

This happens also with onDocument* firestore triggers, basically anything that uses EventArc. GCloud tool seems to have separate trigger-service-account input argument so it is at least possible to define the service account to be used, but can not get it to work with firebase cloud functions. Have tried using the setGlobalOptions as well, but no luck with that neither.

This used to be an issue with the onCall and onRequest as well, but those now work with the latest version of firebase-tools.

Steps to reproduce

Have any kind of trigger cloud function and configure it to use custom service account and have a project that does not have the default compute engine service account which EventArc uses when no service account is defined.

Expected behavior

Deploy works without the error about missing default compute engine service account and the defined service account is used.

Actual behavior

[2024-02-25T18:58:14.315Z] Functions deploy failed.
[2024-02-25T18:58:14.315Z] {
  "endpoint": {
    "id": "automatedBackupFromFirestoreV2",
    "project": "*****",
    "region": "europe-west1",
    "entryPoint": "automatedBackupFromFirestoreV2",
    "platform": "gcfv2",
    "runtime": "nodejs18",
    "scheduleTrigger": {
      "schedule": "every 168 hours",
      "timeZone": null,
      "retryConfig": {}
    },
    "labels": {
      "deployment-tool": "cli-firebase"
    },
    "ingressSettings": null,
    "availableMemoryMb": null,
    "serviceAccount": "compute-engine-default@*****.iam.gserviceaccount.com",
    "timeoutSeconds": null,
    "maxInstances": null,
    "minInstances": null,
    "concurrency": 80,
    "vpc": null,
    "environmentVariables": {
      "BACKUPS_BUCKET": "\"gs://*****",
      "FIREBASE_CONFIG": "{\"projectId\":\"*****\",\"databaseURL\":\"*****\",\"storageBucket\":\"*****\",\"locationId\":\"europe-west\"}",
      "GCLOUD_PROJECT": "*****",
      "EVENTARC_CLOUD_EVENT_SOURCE": "projects/*****/locations/europe-west1/services/automatedBackupFromFirestoreV2"
    },
    "codebase": "default",
    "cpu": 1,
    "securityLevel": "SECURE_ALWAYS",
    "targetedByOnly": true,
    "hash": "*****",
    "uri": "*****",
    "runServiceId": "automatedbackupfromfirestorev2"
  },
  "op": "set invoker",
  "original": {
    "name": "FirebaseError",
    "children": [],
    "exit": 1,
    "message": "Failed to set the IAM Policy on the Service projects/*****/locations/europe-west1/services/automatedbackupfromfirestorev2",
    "original": {
      "name": "FirebaseError",
      "children": [],
      "context": {
        "body": {
          "error": {
            "code": 400,
            "message": "Service account <PROJECTID>[email protected] does not exist.",
            "status": "INVALID_ARGUMENT"
          }
        },
        "response": {
          "statusCode": 400
        }
      },
      "exit": 1,
      "message": "HTTP Error: 400, Service account <PROJECTID>[email protected] does not exist.",
      "status": 400
    },
    "status": 400,
    "code": 400
  }
}

[inlined]

Starting in this week's release, the serviceAccount that the function is configured to run as is the service account the associated service is configured to authorize its requests to the function with.

[sconix]

@inlined First of all thanks for the fixes, secondly I can confirm onSchedule, beforeUserCreated and beforeUserSignedIn to work now with the latest firebase-tools version, but still get the error of default compute-engine SA not existing when deploying onDocumentWritten trigger functions. Let me know if you want me to create a new issue about this.

[inlined]

Will look into it this week. Also, FYI, I've submitted a proposal to add triggerServiceAccount to the function options. I would not be surprised if the API council makes me revert this change to use serviceAccount as a backup since it was a breaking change that broke someone and you may have to use this new field in a future release.

[sconix]

@inlined any progress on this? At least have not spotted any fixes yet in the release notes regarding this. We are currently stuck in gen1/gen2 hybrid setup because of this issue so even not super critical would be really nice to be able to move fully to gen2 stuff. Thank you again for looking into this.

[ushuz]

but still get the error of default compute-engine SA not existing when deploying onDocumentWritten trigger functions

We ran into this issue as well.

Even though the function now supports specifying custom service accounts, it seems Firebase CLI (firebase deploy) is hardcoded to only work with the default compute-engine SA: https://github.com/firebase/firebase-tools/blob/e1ff423e538b0e520887915dcdbb202546d76a7c/src/deploy/functions/checkIam.ts#L201 https://github.com/firebase/firebase-tools/blob/e1ff423e538b0e520887915dcdbb202546d76a7c/src/deploy/functions/checkIam.ts#L156-L157

[sconix]

@inlined @joehan any possibility to get this finally finished? We are still stuck on hybrid gen1/gen2 setup because of this not working. Would creately appreciate if this could be fixed.

[brantgurga]

Ran into this recently and put in ticket/request via support channels too. onSchedule sets up the service account as an invoker. All the eventarc stuff like onDocumentWritten sets the service account on the trigger and on the function, but it does not set the account as an invoker.

[ristokyotikki]

Hello, I'm also experiencing the same issue with onDocumentWritten cloud functions. I'd want to fully transition to gen2, but this current behavior is preventing that. I would greatly appreciate it if this could be addressed and a fix implemented. Thank you for your time and attention to this matter.

[brantgurga]

@ristokyotikki Through support, I came up with giving the service account an invoker role globally. That could work for you. Instead of invoker specifically on the function, it'd be a project-wide invoker. Whether that increased breadth is acceptable is up to you.