serverless-google-cloudfunctions
serverless-google-cloudfunctions copied to clipboard
Setting IAM policy causes deploy failure
I recently added support for IAM policies (https://github.com/serverless/serverless-google-cloudfunctions/pull/219), and it appears that using it is causing deploys to fail (https://github.com/serverless/serverless-google-cloudfunctions/pull/219#issuecomment-649422035)
After overwriting my local compileFunction.js
in my node_modules (probably a dumb question, but since I don't use npm/node often -- is there an easier way to reference a branch/local copy other than just overwriting the file?) and running a deployment
service: test-api
provider:
name: google
stage: dev
runtime: python37
memorySize: 128
region: us-central1
project: [project id]
credentials: ~/.gcloud/keyfile.json
plugins:
- serverless-google-cloudfunctions
package
excludeDevDependencies: true
exclude:
- node_modules/**
- .gitignore
- .git/**
functions:
first:
handler: http
events:
- http: path
allowUnauthenticated: true
I got a similar error as to the one described in the PR comment
Error: Deployment failed: RESOURCE_ERROR
{"ResourceType":"gcp-types/cloudfunctions-v1:projects.locations.functions","ResourceErrorCode":"404","ResourceErrorMessage":{"statusMessage":"Not Found","requestPath":"https://cloudfunctions.googleapis.com/v1/:setIamPolicy","httpMethod":"POST"}}
at throwErrorIfDeploymentFails (/Users/edaniszewski/dev/test-api/node_modules/serverless-google-cloudfunctions/shared/monitorDeployment.js:71:11)
at /Users/edaniszewski/dev/test-api/node_modules/serverless-google-cloudfunctions/shared/monitorDeployment.js:42:17
at processTicksAndRejections (internal/process/task_queues.js:89:5)
From previous event:
at PluginManager.invoke (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:489:22)
at /usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:524:24
From previous event:
at PluginManager.run (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:524:8)
at /usr/local/lib/node_modules/serverless/lib/Serverless.js:131:33
From previous event:
at Serverless.run (/usr/local/lib/node_modules/serverless/lib/Serverless.js:118:74)
at /usr/local/lib/node_modules/serverless/bin/serverless.js:80:26
at processImmediate (internal/timers.js:439:21)
at process.topLevelDomainCallback (domain.js:126:23)
From previous event:
at Object.<anonymous> (/usr/local/lib/node_modules/serverless/bin/serverless.js:80:4)
at Module._compile (internal/modules/cjs/loader.js:774:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:785:10)
at Module.load (internal/modules/cjs/loader.js:641:32)
at Function.Module._load (internal/modules/cjs/loader.js:556:12)
at Function.Module.runMain (internal/modules/cjs/loader.js:837:10)
at internal/main/run_main_module.js:17:11
The interesting bit to me: https://cloudfunctions.googleapis.com/v1/:setIamPolicy
which didn't look right. Looking at the cloudfunctions API doc (https://cloud.google.com/functions/docs/reference/rest/v1/projects.locations.functions/setIamPolicy?hl=fa), the request should be:
POST https://cloudfunctions.googleapis.com/v1/{resource}:setIamPolicy
So, it appears that the resource identifier isn't being set in the API call.
I'll try to dig into this a bit more, but since I'm relatively new to the code base, any pointers on where I should look are appreciated (:
And also apologies for not catching this and fixing this while it was in a PR.
@edaniszewski thanks for looking into it. I'm not going to publish new version, once we sort this out. If it's time taking, then probably we need to revert this change for now
(sorry for confusing comments, I deleted them. I thought it's someone else that reports the problem again :)
Based on the following, it seems like this is an issue w/ the cloud functions / deployment manager api
- https://stackoverflow.com/questions/62576013/how-to-set-iam-policy-to-cloud-function-with-deployment-manager
- https://github.com/GoogleCloudPlatform/deploymentmanager-samples/issues/494
I haven't yet read through the entire issue thread, but It looks like there are workarounds, so there seems to be a path forward for this.
As an update, I've cobbled together a minimal implementation for setting IAM policies which appears to work. I'll spend some time over the next day or two cleaning it up and will open a PR when ready.