I am experiencing a very similar issue with a v1 function that uses an onCreate Firebase Auth trigger and tries to access Firestore. As a weird thing, it looks like despite it being a v1 function and what the docs say, firebase deploy does not set [email protected] as permission but uses [email protected]. I don't know yet if that's the cause.

Using the default service account is not working but creating one, giving Cloud datastore user role, and associating this service account to the function fixes the issue.

What is weird is that I didn't touch permissions for the default service account so that's strange that some actions started to fail suddenly.

Something similar happened to me as well where I started losing permission access to my functions. I know that v1 functions use the App Engine default service account, and v2 functions use the Compute Engine service account, and it does seem like their wires got crossed somewhere lately and I started assigning function permissions to both just to be safe.

I did notice that a few weeks ago when I would few my v2 function on the Cloud Functions dashboard, it would show the same function endpoint as on the Cloud Run dashboard (e.g. functionname-projectslug-uc.a.run.app), but now on the functions dashboard it shows the old v1 endpoint format us-central1-project-name.cloudfunctions.net/functionName, and the Cloud Run dashboard shows the former endpoint separately. Maybe these are correlated and maybe they're not, but these two services are closely connected behind the scenes.

We are having a similar issue. We have a utility trigger that injects a timestamp value when a document is created or updated for auditing (very similar to OP). The only thing the trigger does is add/edit a value with a ISO date string. The code works on gen 1 with the only change being changing to use gen 2.

The error in full:

 Error: 7 PERMISSION_DENIED: Missing or insufficient permissions.
    at callErrorFromStatus (/workspace/node_modules/@grpc/grpc-js/build/src/call.js:31:19)
    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client.js:192:76)
    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:360:141)
    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:323:181)
    at /workspace/node_modules/@grpc/grpc-js/build/src/resolving-call.js:94:78
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) 

We are using node 18 and keep all our dependencies up to date.

Same issue here, but with firestore. Any news?

Same issue here, but with firestore. Any news?

@taeold ?

Same issue here, but with firebase-admin

Hi folks. This issue seems to me like an issue with the default service accounts associated with the function. Usually, these service accounts are granted Editor role which grants wide-array of permissions like ability to read/write to Firestore.

However, there are organizational/security policies that prevents automatically grants the default service account the Editor role:

https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants

You can always manually grant the Editor role to your default service account via by visiting GCP IAM page:

Can someone confirm if the organizational policy could be at fault here?

Hey @kevinnammour. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

@taeold No, still fails after manually editing the service account.

Hey @kevinnammour. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

@google-oss-bot @taeold what information do you need? This is getting ridiculous.

Hello, could you solve the issue?

Hello, could you solve the issue?

no

Hi folks. This issue seems to me like an issue with the default service accounts associated with the function. Usually, these service accounts are granted Editor role which grants wide-array of permissions like ability to read/write to Firestore.

However, there are organizational/security policies that prevents automatically grants the default service account the Editor role:

https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants

You can always manually grant the Editor role to your default service account via by visiting GCP IAM page:

Genration Service account name Email address
Gen1 App Engine default service account {project-id}@appspot.gserviceaccount.com
Gen2 Compute Engine default service account {project-number}[email protected]
Can someone confirm if the organizational policy could be at fault here?

@taeold what information do you need? This is ridiculous.

Same here - Google Firestore no longer accessible from my nodeJS server application.

From a perfectly working code, all I did was updating my packages.

I am using the following dependencies:

"dependencies": {
    "@google-cloud/firestore": "^7.1.0",
    "@nestjs/common": "^10.2.10",
    "@nestjs/config": "^3.1.1",
    "@nestjs/core": "^10.2.10",
    "@nestjs/platform-express": "^10.1.10",
    "@nestjs/schedule": "^4.0.0",
    "firebase-admin": "^11.11.1",
    "fireorm": "^0.23.3",
    "nestjs-fireorm": "^1.1.0",
  },

Any trial to access (read/write/update) a firestore collection results in this error message:

Error: 7 PERMISSION_DENIED: Missing or insufficient permissions

Even if I give full access in the Firestore RULES !!!!!

What is going wrong here ???

@taeold what information do you need? This is ridiculous.

@Blunderchips Screenshot you shared doesn't give me any additional information about your setul

@iKK001 FWIW, security rules are not enforced when you access the database via the Admin SDK.

I recommend folks experiencing the issue to open up a Firebase Support case so we can take a look at your project on a case-by-case basis. If I notice any general trends, I'll share them here, but it's unclear to me whether there is a bug in the Functions SDK that's affecting everyone.

@taeold what information do you need? This is ridiculous.

@Blunderchips Screenshot you shared doesn't give me any additional information about your setul

@iKK001 FWIW, security rules are not enforced when you access the database via the Admin SDK.

I recommend folks experiencing the issue to open up a Firebase Support case so we can take a look at your project on a case-by-case basis. If I notice any general trends, I'll share them here, but it's unclear to me whether there is a bug in the Functions SDK that's affecting everyone.

@taeold what information do you need?

From my side, I can give "much lower sound" to the warning: i.e. I did a mistake calling the wrong environment-variable.

Running locally, I do the following steps and it works now:

Step1:
In the Firestore Project-Settings page, under the Tab "Service Accounts", I press the Button "Generate new private key" to donwload the credentials-json file.

Step2:
I place the file in my root-folder of my project (I might rename it to something like DO-NOT-EDIT.dev.fb-admin-sdk-key.json

Step3:
I add the credential-json Filename to the .gitignore file (since this should not be pushed to the repo). And also add the .env-file inside the gitignore file.

Step4:
In my nodeJS-server-code I type:

export const firebaseApp = admin.initializeApp({
  credential: admin.credential.cert({
    privateKey: process.env.PRIVATE_KEY,
    clientEmail: process.env.CLIENT_EMAIL,
    projectId: process.env.PROJECT_ID,
  }),
  databaseURL: `https://${process.env.PROJECT_ID}.firebaseio.com`,
});

(i.e. the 3 environment variables PRIVATE_KEY, CLIENT_EMAIL, PROJECT_ID I take form the downloaded json-file and add them to a seprate .env file. Just because the 3 are the only ones used later in your remote Cloud Run application !!!!)

Remark1: I do not use the possibility explained in the Firestore Project-Settings/Service-accounts

var admin = require("firebase-admin");

var serviceAccount = require("/Users/my_account/my_path/DO-NOT-EDIT.dev.fb-admin-sdk-key.json");

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount)
});

I do not use the above code. It would work locally, no problem. But I prefer the above version since I do not want to push the json-file to the repo later on. I want to do it with envrionment variables.

Remark2: if you use the environment-variable case (first code-sample shown above), then make sure to format the environment variables correctly !!!

The envrionment variables look something like this:

# DEV
PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCyDg4k+fCWc+kV
xjJqBx3hcOCD2UBiixXSOEUDbfME/f9WTPuJHWDyaIv305hieHXbZKyUSH2nO0CT
nUQMqZktykZbhIp6vMxFrvRTDH3MFBvGcWOcA+Adt6H4gnOYJPtr5EvhUBHARXDY
...much longer....
UbCDz5L17w0kGeTRnSiEgossnN3ZjbcAAV7DCC6UQFQb4scA3HF+Pw1zvuhkGiR/
FaV7ADrMMZL9d/wo8oJE72rf8pqVQcSGwv04sORE3TdmnCn1/+NnCqYhUR8QiAuw
K2cR2BT9kfe7xCCr3gSxCkN7tuSHsrSo24B+BaSVAoGBALKz7wyU4OcLKnCxhKQ3
a6u7CBLg3sajpfH6WT5C8Z0sY6/cmToL/UnGKOdNuulsWg3lWusqYOag6dRbLqDq
/DOCBF1eYaimgEdbzAWIq2WFTCmHJdCQh6DmZjKtp0KHzeMAy/rq99GE3WP11xMd
RGEeYbJvwfZFAH4ocHyORRt8
-----END PRIVATE KEY-----"
CLIENT_EMAIL="firebase-adminsdk-gi7v0@<my_proj_name>.iam.gserviceaccount.com"
PROJECT_ID="my_proj_name"

Again, you can find those values inside the downloaded DO-NOT-EDIT.dev.fb-admin-sdk-key.json file !!
Just make sure the key is formatted as shown (i.e. eliminate the carriage return signs "\n").

However, and this was my mistake, running this locally, next to the required env-vars just created inside the .env file), YOU ABSOLUTELY NEED TO EXECUTE THE FOLLOWING export :

Step5:
In my Terminal I write:

export GOOGLE_APPLICATION_CREDENTIALS="/Users/my_account/my_path/DO-NOT-EDIT.dev.fb-admin-sdk-key.json"

(or whatever name you gave your file)

The GOOGLE_APPLICATION_CREDENTIALS is needed to run your sever locally. It is no longer needed when run in Google Cloud Run (when provided by the 3 env vars from above).

It works now with this knowlege, hopefully also for everybody reading this.

P.S.
Some ideas to lower confusion on this topic and how to improve documentation :

• increase detail of error-message (i.e. after all, the simple message insufficient permissions can mean anything). Improve the level of detail and explain in the error-message where and what exactly is failing. (for example "missing cert credentials during admin.initializeApp - maybe due to missing environment variables" or anything to that respect...
• improve documentation for the two distincs cases: 1. running the nodeJs-server code locally in a terminal / or 2. running the nodeJS-server on a Google Cloud Run container. So far, the differences are not clear. (i.e. such as env-var handling vs. IAM-credentials vs. Secret Manager stuff). Totally too little documentation on this.

From my side, I can give "much lower sound" to the warning: i.e. I did a mistake calling the wrong environment-variable.

Running locally, I do the following steps and it works now:

Step1: In the Firestore Project-Settings page, under the Tab "Service Accounts", I press the Button "Generate new private key" to donwload the credentials-json file.

Step2: I place the file in my root-folder of my project (I might rename it to something like DO-NOT-EDIT.dev.fb-admin-sdk-key.json

Step3: I add the credential-json Filename to the .gitignore file (since this should not be pushed to the repo). And also add the .env-file inside the gitignore file.

Step4: In my nodeJS-server-code I type:

export const firebaseApp = admin.initializeApp({
  credential: admin.credential.cert({
    privateKey: process.env.PRIVATE_KEY,
    clientEmail: process.env.CLIENT_EMAIL,
    projectId: process.env.PROJECT_ID,
  }),
  databaseURL: `https://${process.env.PROJECT_ID}.firebaseio.com`,
});

(i.e. the 3 environment variables PRIVATE_KEY, CLIENT_EMAIL, PROJECT_ID I take form the downloaded json-file and add them to a seprate .env file. Just because the 3 are the only ones used later in your remote Cloud Run application !!!!)

Remark1: I do not use the possibility explained in the Firestore Project-Settings/Service-accounts

var admin = require("firebase-admin");

var serviceAccount = require("/Users/my_account/my_path/DO-NOT-EDIT.dev.fb-admin-sdk-key.json");

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount)
});

I do not use the above code. It would work locally, no problem. But I prefer the above version since I do not want to push the json-file to the repo later on. I want to do it with envrionment variables.

Remark2: if you use the environment-variable case (first code-sample shown above), then make sure to format the environment variables correctly !!!

The envrionment variables look something like this:

# DEV
PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCyDg4k+fCWc+kV
xjJqBx3hcOCD2UBiixXSOEUDbfME/f9WTPuJHWDyaIv305hieHXbZKyUSH2nO0CT
nUQMqZktykZbhIp6vMxFrvRTDH3MFBvGcWOcA+Adt6H4gnOYJPtr5EvhUBHARXDY
...much longer....
UbCDz5L17w0kGeTRnSiEgossnN3ZjbcAAV7DCC6UQFQb4scA3HF+Pw1zvuhkGiR/
FaV7ADrMMZL9d/wo8oJE72rf8pqVQcSGwv04sORE3TdmnCn1/+NnCqYhUR8QiAuw
K2cR2BT9kfe7xCCr3gSxCkN7tuSHsrSo24B+BaSVAoGBALKz7wyU4OcLKnCxhKQ3
a6u7CBLg3sajpfH6WT5C8Z0sY6/cmToL/UnGKOdNuulsWg3lWusqYOag6dRbLqDq
/DOCBF1eYaimgEdbzAWIq2WFTCmHJdCQh6DmZjKtp0KHzeMAy/rq99GE3WP11xMd
RGEeYbJvwfZFAH4ocHyORRt8
-----END PRIVATE KEY-----"
CLIENT_EMAIL="firebase-adminsdk-gi7v0@<my_proj_name>.iam.gserviceaccount.com"
PROJECT_ID="my_proj_name"

Again, you can find those values inside the downloaded DO-NOT-EDIT.dev.fb-admin-sdk-key.json file !! Just make sure the key is formatted as shown (i.e. eliminate the carriage return signs "\n").

However, and this was my mistake, running this locally, next to the required env-vars just created inside the .env file), YOU ABSOLUTELY NEED TO EXECUTE THE FOLLOWING export :

Step5: In my Terminal I write:

export GOOGLE_APPLICATION_CREDENTIALS="/Users/my_account/my_path/DO-NOT-EDIT.dev.fb-admin-sdk-key.json"

(or whatever name you gave your file)

The GOOGLE_APPLICATION_CREDENTIALS is needed to run your sever locally. It is no longer needed when run in Google Cloud Run (when provided by the 3 env vars from above).

It works now with this knowlege, hopefully also for everybody reading this.

P.S. Some ideas to lower confusion on this topic and how to improve documentation :

• increase detail of error-message (i.e. after all, the simple message insufficient permissions can mean anything). Improve the level of detail and explain in the error-message where and what exactly is failing. (for example "missing cert credentials during admin.initializeApp - maybe due to missing environment variables" or anything to that respect...
• improve documentation for the two distincs cases: 1. running the nodeJs-server code locally in a terminal / or 2. running the nodeJS-server on a Google Cloud Run container. So far, the differences are not clear. (i.e. such as env-var handling vs. IAM-credentials vs. Secret Manager stuff). Totally too little documentation on this.

We have tried this in the past to no success. Then "Running locally" does not resolve any issues, our code works perfectly fine locally. Everything works fine deployed to functions gen1 but fails on functions gen2, the only changes being those needed for migrating to gen2.

I'm unable to reproduce this issue with V1 or V2 functions. @kevinnammour is this still something you can reproduce?

V1 function

export const setTimestampsOnCreateV1 = firebase.firestore.document("listings/{listingId}").onCreate((snapshot) => {
    const currentTime = admin.firestore.FieldValue.serverTimestamp();
    if (!snapshot || !snapshot.exists) {
        logger.info("No snapshot found, exiting");
        return;
    }

    return snapshot.ref.set(
        {
            createdAt: currentTime,
            updatedAt: currentTime,
        },
        {
            merge: true,
        }
    );
});

V2 function

export const setTimestampsOnCreateV2 = onDocumentCreated("listings/{listingId}", (event) => {
    const currentTime = admin.firestore.FieldValue.serverTimestamp();
    const snapshot = event.data;
    if (!snapshot || !snapshot.exists) {
        logger.info("No snapshot found, exiting");
        return;
    }

    return snapshot.ref.set(
        {
            createdAt: currentTime,
            updatedAt: currentTime,
        },
        {
            merge: true,
        }
    );
});

Yes @exaby73 this is still an issue. It seems to only be reproduceable in firebase projects created before a certain date. The issue seems to be with the service accounts that are being generated by firebase.

Facing very much the same issue with a NextJS/React app. Key facts:

• Service account checked and app initialized properly on a server route
• Client access works as expected
• When Firestore access rules are wide open (allow read, write: if true) then both client and admin works
• When access rules require an authenticated user (allow read, write: if request.auth.uid != null), the client side continues to work, while the server calls throw the permission error
• When access rules are closed (allow read, write: if false), neither works

Initializing the app with the json file, or with the private key or with GOOGLE_APPLICATION_CREDENTIALS makes no difference. None of the methods from https://firebase.google.com/docs/auth/admin/create-custom-tokens seems to have worked.

Per the guide:

If the Firebase Admin SDK has to discover a service account ID string, it does so when your code creates a custom token for the first time. The result is cached and reused for subsequent token signing operations. The auto-discovered service account ID is usually one of the default service accounts provided by the Google Cloud:

Default Compute Engine service account
Default Cloud Functions service account

Checking both service accounts, they have the Editor and Cloud Datastore User permissions.

Any tips will be appreciated.

Currently having the same issue as @gursesl with my .Net Core Firebase Admin SDK. Everything works fine (for authentication, messaging, etc) except when I try to access my firestore database then I get Grpc.Core.RpcException: Status(StatusCode="PermissionDenied", Detail="Missing or insufficient permissions."). Been trying to get it to work since two days now but no success. I have also tried setting permissions to the admin SDK service account via GCP but still getting the same error..

Just like @gursesl, any tips will be appreciated.

Hey @kevinnammour. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

Since there haven't been any recent updates here, I am going to close this issue.

@kevinnammour if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

still issue

Hi folks. This issue seems to me like an issue with the default service accounts associated with the function. Usually, these service accounts are granted Editor role which grants wide-array of permissions like ability to read/write to Firestore.

However, there are organizational/security policies that prevents automatically grants the default service account the Editor role:

https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants

You can always manually grant the Editor role to your default service account via by visiting GCP IAM page:

Genration Service account name Email address
Gen1 App Engine default service account {project-id}@appspot.gserviceaccount.com
Gen2 Compute Engine default service account {project-number}[email protected]
Can someone confirm if the organizational policy could be at fault here?

Hello!

This works for me!

Granted the Editor role to my [project-id][email protected] in IAM permissions in Google Cloud Console.

If anyone still facing this issue, the first step is to ensure that you're logged in with the correct Firebase account using the Firebase CLI.

Hi folks. This issue seems to me like an issue with the default service accounts associated with the function. Usually, these service accounts are granted Editor role which grants wide-array of permissions like ability to read/write to Firestore.
However, there are organizational/security policies that prevents automatically grants the default service account the Editor role:
https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants
You can always manually grant the Editor role to your default service account via by visiting GCP IAM page:
Genration Service account name Email address
Gen1 App Engine default service account {project-id}@appspot.gserviceaccount.com
Gen2 Compute Engine default service account {project-number}[email protected]
Can someone confirm if the organizational policy could be at fault here?

Hello!

This works for me!

Granted the Editor role to my [project-id][email protected] in IAM permissions in Google Cloud Console.

Also worked for me!!
Although I am using Gen1 I had to give to Compute Engine the Editor role

Thanks

Hi folks. This issue seems to me like an issue with the default service accounts associated with the function. Usually, these service accounts are granted Editor role which grants wide-array of permissions like ability to read/write to Firestore.

However, there are organizational/security policies that prevents automatically grants the default service account the Editor role:

https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_default_grants

You can always manually grant the Editor role to your default service account via by visiting GCP IAM page:

Genration Service account name Email address
Gen1 App Engine default service account {project-id}@appspot.gserviceaccount.com
Gen2 Compute Engine default service account {project-number}[email protected]
Can someone confirm if the organizational policy could be at fault here?

This!!

@lpellegr I get insufficient permissions with a version 1 functions call

export const setupNewUser = userAuth.user().onCreate(async (user)=>{
  const {displayName, photoURL, uid} = user;
  const appV1 = initializeAppV1(firebaseConfig);
  const db = getFirestoreV1(appV1);

  log("start writing to domains");

  const domainDocRef = await addDoc(collection(db, "domains"),
    {
      version: 0,
      generation: 0,
...

in which I try to set up a user, account (and two more) documents.

You say "[1]creating one [service account], [2]giving Cloud datastore user role, and [3]associating this service account to the function fixes the issue.", but I don't know how to do any of of those three things. Can you direct me to some documentation?

Thanks.

@lpellegr Never mind, I've decide to abandon this snake pit, and do the onCreate and onDelete procedures at the front end.

As a general comment, I'm a bit surprised that there is such a snake pit! It's Firebase!!

I was able to get this to work when deploying via a github action by manually specifying the compute engine service account within the gcloud cli command per these instructions.
--service-account SERVICE_ACCOUNT_EMAIL

The permission recommendations suggest to remove the Editor role:

3 service accounts with highly privileged roles Owner / Editor have excess permissions.

I applied the recommendation some time ago. Reverted it now. Functions work again.

I was able to get this to work when deploying via a github action by manually specifying the compute engine service account within the gcloud cli command per these instructions. --service-account SERVICE_ACCOUNT_EMAIL

Amazing, mate! This worked for me! I had this issue with Cloud Run, and it seems the only fix is exactly what you mentioned—manually configuring the Compute Engine service account using the gcloud CLI command. After the frustration of trying the other solutions, I gave yours a shot, and voilà! Fixed! Thanks a ton!

Took a minute or two after the change was saved, but granting the Editor role to my Compute service account in the IAM console also worked for me.

I am having the same issues. All of a sudden my cloudrun service cant access my Firestore database anymore. I have tried to change the permissions of my service account in IAM but without any success.

Still having this issue

I had this problem after updating my versions of various libraries:

• firebase-functions from v4.5.0 to v6.1.1
• firebase-admin from 12.0.0 to v13.0.1
• @google-cloud/firestore from 4.15.1 to 7.11.0

But it disappeared when I started importing and using a Firestore object from firebase-admin rather than @google-cloud/firestore.

Thanks to everyone on here who added all the information. I encountered a subset of similar problems when migrating my project from a personal google account to my organization's.

First, I was unable deploy my firebase functions to the new account, an error returned:

Gen1 operation for function myFunction:(leaving out path) Build failed: failed to Fetch: failed to download archive gs://gcf-sources-XXXXXXXXX-us-central1/rXXXXXX-XXXXX-XXXX-XXXX-XXX-XXXXXXXXXXX/version-1/function-source.zip: Access to bucket XXXXXX denied. You must grant Storage Object Viewer permission to [email protected]. If you are using VPC Service Controls, you must also grant it access to your service perimeter.

The error message listed the service account that was being used to deploy the functions. When I checked IAM accounts, it was not listed. I had to add the account manually and grant it the Storage Object Viewer permission. I believe I had to grant it a couple other permissions but I cannot recall. These were useful in figuring out what to change:

• https://cloud.google.com/functions/docs/securing/managing-access-iam#enabling_access_to_a_function
• https://cloud.google.com/functions/docs/troubleshooting#build-service-account

Once the permissions were added, the error messaged changed to something along the lines of:

Unable to set the invoker for the IAM policy on the following functions

So while the functions were deploying, the system wasn't able to invoke them as part of the process. I was able to fix this with this information:

• Unable to set the invoker for the IAM policy on the following functions firebase-tools#6017 (comment)

Thank you @gOzaru! It works for me. I want to share the steps I had to take:

1. Go to IAM and admin > IAM (link)
2. Make sure the organisation is selected in the dropdown at the top (not a project)
3. For the profile with the “Organisation Administrator”, click on the pencil “Edit principal”
4. Click on “ADD ANOTHER ROLE”
5. Choose “Organisation Policy Administrator” (necessary to edit policies in the next step)
6. Go to IAM and admin > Organisation policies (link)
7. Click on “Domain restricted sharing”
8. Click on “MANAGE POLICY”, leave everything as default and remove any existing rules.
9. Click “ADD A RULE” and add choose “Allow all”
10. Finally click “SET POLICY”
11. Now you should be able to deploy the cloud functions

I am pretty sure I also had to go to Cloud Run Functions in google cloud console, check all my functions and add a principal to them, AllUsers or AllAuthenticatedUsers so my app could invoke the functions.

I was able to deploy the functions but then I was unable to run it as per THIS ISSUE because permission was DENIED. I was able to grant permissions this way:

• https://cloud.google.com/functions/1stgendocs/securing/function-identity#gcloud_1
• https://cloud.google.com/appengine/docs/legacy/standard/python/service-account

I believe what has happened is related to Google making changes on policy.

• "Depending on your organization policy configuration, the default service account might automatically be granted the Editor role on your project. We strongly recommend that you disable the automatic role grant by enforcing the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint. If you created your organization after May 3, 2024, this constraint is enforced by default."

So if you created a project after May 3, 2024 the app service account did not get an IAM policy and has no permissions. The really messed up part, specially for me (not experienced), is that IAM list a number of accounts associated to the project but not the app service account. I was granting editor roles to all the accounts listed with no avail. IF you access service accounts through cloud console or the last link listed just above, you would see that the app service account is listed. It is normally [email protected]. IF you go and check IAM and that account is not listed, you need to add it manually and give it editor role. In my case I gave it that and Firestore Service Agent because my issue was related to firestore access.

After doing this, it didn't work immediately but 3 or 5 minutes later the functions started to execute appropriately. I think all this information is already posted in different forms, hope this clarifies it a bit.