Repository navigation
docs(taskqueues): spell out the IAM bindings and add the Python README - #1341
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Node.js task queue backup images README with clearer IAM instructions and troubleshooting tips, and adds a comprehensive README for the Python version of the sample. The review feedback suggests updating the IAM policy command in the Python README to use gcloud run services add-iam-policy-binding instead of gcloud functions add-iam-policy-binding for 2nd gen Cloud Functions.
| gcloud functions add-iam-policy-binding backupapod \ | ||
| --region=us-east4 \ | ||
| --member=serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ | ||
| --role=roles/run.invoker |
There was a problem hiding this comment.
For 2nd gen Cloud Functions, the underlying service is a Cloud Run service. The recommended and standard way to grant the invoker role is using gcloud run services add-iam-policy-binding instead of gcloud functions add-iam-policy-binding.
| gcloud functions add-iam-policy-binding backupapod \ | |
| --region=us-east4 \ | |
| --member=serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ | |
| --role=roles/run.invoker | |
| gcloud run services add-iam-policy-binding backupapod \ | |
| --region=us-east4 \ | |
| --member=serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ | |
| --role=roles/run.invoker |
|
Changed the |
The Python sample sets no region, so it deploys to us-central1. #1347 puts the other sample URLs back to us-central1 as well.
The Node.js sample passes no uri when it enqueues tasks; the Admin SDK resolves the URL from the queue name. Name the binding requiresRole doesn't grant, say how to target a function in another region (#1002), and mention the Python SDK version that rejected Cloud Tasks tokens (firebase-functions-python#157).
With requiresRole, the Firebase CLI creates a service account for the codebase and runs every function as it, so the by-hand roles/iam.serviceAccountUser binding must target that account, not the Compute Engine default.
b0cd63a to
031e901
Compare
1 participant
One step in the IAM section of
Node/taskqueues-backup-images/README.mdsaid only "follow Google Cloud IAM documentation to add App Engine default service account as user of App Engine default service account". #1088 points out that this doesn't say which role to grant or how. The step now names the role (roles/iam.serviceAccountUser) and gives thegcloudcommand. A short paragraph explains the401/403errors that #1088, #1105, and #1143 ran into when a binding is missing.The section also names the right identity. The sample uses
requiresRole(), and with it the Firebase CLI creates a service account for the codebase (firebase-fn-…@<project-id>.iam.gserviceaccount.com), grants it the declared roles, and runs every function as that account (firebase-toolsdiscoverSecurityDetails). The old text said the Compute Engine default service account, which would have sent you to bind the wrong account. Thegcloudcommands now use a${FUNCTIONS_SA}placeholder for that email, and a sentence says when the Compute Engine default applies instead (if you removerequiresRole).Python/taskqueues-backup-images/README.mdwas a one-line stub. It now describes the two functions, setup, deployment, and the same IAM bindings. The Python SDK has no equivalent ofrequiresRole(), so those functions run as the Compute Engine default service account and the README says to grant the roles withgcloud.Fixes #1088
Related: #1105, #1143
Verification
Docs only. The
gcloudcommands follow the pattern already used in the Node.js README. Not deployed; the managed service account behavior comes from the firebase-tools source linked above.