cloud function error: PERMISSION_DENIED: Missing or insufficient permissions

[kevinnammour]

Related issues

[REQUIRED] Version info

node: v18.16.0

firebase-functions: 4.3.1

firebase-tools: 12.4.0

firebase-admin: 11.8.0

[REQUIRED] Test case

I have successfully deployed a cloud function: but it gives PERMISSION_DENIED when triggered.

[REQUIRED] Steps to reproduce

import * as functions from "firebase-functions";
import * as admin from "firebase-admin";

admin.initializeApp();

export const setTimestampsOnCreate = functions.firestore
  .document("listings/{listingId}")
  .onCreate((snapshot) => {
    const currentTime = admin.firestore.FieldValue.serverTimestamp();
    return snapshot.ref.set(
      {
        createdAt: currentTime,
        updatedAt: currentTime,
      },
      {
        merge: true,
      }
    );
  });

Then, firebase deploy.

[REQUIRED] Expected behavior

createdAt and updatedAt appear in the new listing document.

[REQUIRED] Actual behavior

Nothing appears, and this appears in the Logs Explorer of that function:

{
  "textPayload": "Error: 7 PERMISSION_DENIED: Missing or insufficient permissions.\n    at callErrorFromStatus (/workspace/node_modules/@grpc/grpc-js/build/src/call.js:31:19)\n    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client.js:192:76)\n    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:360:141)\n    at Object.onReceiveStatus (/workspace/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:323:181)\n    at /workspace/node_modules/@grpc/grpc-js/build/src/resolving-call.js:94:78\n    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)",
  "insertId": "648c880e000cfb9650c27bb0",
  "resource": {
    "type": "cloud_function",
    "labels": {
      "region": "us-central1",
      "function_name": "setTimestampsOnCreate",
      "project_id": "dormati-b29a7"
    }
  },
  "timestamp": "2023-06-16T16:04:30.850838Z",
  "severity": "ERROR",
  "labels": {
    "execution_id": "o5u6vlzf6e9r",
    "instance_id": "00c61b117c826b7c9fc18c8a07396f9e616a78e6c171e68f19f1883509553185306afbb9d971675d3d2c7342435e696a0c175110b72872058288"
  },
  "logName": "projects/dormati-b29a7/logs/cloudfunctions.googleapis.com%2Fcloud-functions",
  "trace": "projects/dormati-b29a7/traces/3ad8e82b637efdf9568fc980600644e0",
  "receiveTimestamp": "2023-06-16T16:04:31.075976411Z"
}

Were you able to successfully deploy your functions?

Yes

[lpellegr]

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 PROJECT_ID@appspot.gserviceaccount.com as permission but uses PROJECT_ID-compute@developer.gserviceaccount.com. I don't know yet if that's the cause.

[lpellegr]

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.

[trevor-rex]

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.

[Blunderchips]

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.

[n-sviridenko]

Same issue here, but with firestore. Any news?

[Blunderchips]

Same issue here, but with firestore. Any news?

@taeold ?

[syedashar1]

Same issue here, but with firebase-admin

[taeold]

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}-compute@developer.gserviceaccount.com

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

[google-oss-bot]

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!

[Blunderchips]

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

[google-oss-bot]

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!

[Blunderchips]

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

[marioluquem]

Hello, could you solve the issue?

[Blunderchips]

Hello, could you solve the issue?

no

[Blunderchips]

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}-compute@developer.gserviceaccount.com Can someone confirm if the organizational policy could be at fault here?

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

[iKK001]

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]

@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.

[Blunderchips]

@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?

[iKK001]

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.

[Blunderchips]

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.

[Blunderchips]

@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.

Firebase support team seems to be maintaining that there is no issue.

[exaby73]

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,
        }
    );
});

[Blunderchips]

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.

[gursesl]

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.

[kent2cky]

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.

[google-oss-bot]

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]

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.

[Blunderchips]

The official firebase position ™ on bugs seem to be ignore an issue until the bot closes it. When in doubt, add "Needs: Author Feedback" then ignore the authors feedback.

[Hadevs]

I have the same problem with my new cloud functions, previous 2 are working well...

UPD: Recreated new function, now see this error:

/**

• Internal errors. Means some invariant expected by underlying system has been broken. If you
• see one of these errors, something is very broken. */ case internal = 13

[hirelynk-branden]

still issue

[igorjacauna]

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}-compute@developer.gserviceaccount.com 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]-compute@developer.gserviceaccount.com in IAM permissions in Google Cloud Console.

[t-genc]

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.

[ferolpt]

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}-compute@developer.gserviceaccount.com 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]-compute@developer.gserviceaccount.com 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

[insivika]

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}-compute@developer.gserviceaccount.com Can someone confirm if the organizational policy could be at fault here?

This!!

[HenrikBechmann]

@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.

[HenrikBechmann]

@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!!