Cloud Build of Firebase Functions works, but does it float?

This is a series of posts exploring Firebase as a serverless webapp in a small one-person team. Can it balance ease of use with solid development?

What went well in gcloud

• ✅ continuous deployment (CD) of Firebase Functions through Cloud Build. This is perfect for a single person setup!!
• ✅ the build and deployment completes in about 4min 30s which is decent.
• ✅ configured Cloud Build to use a firebase containerised image and firebase project’s service account, so the compatibility of moving it out of a local machine was absolutely seamless (no secrets in build, secrets continue to be in Firebase Admin Config)!!!
• ✅ continuous integration (CI) of Cloud Build through github triggers was simple to setup.

Conclusion

This does fit the bill to a t, in the objective of going serverless for a small team, it is ideal. The automation of deployment will make life easier on many levels — consistency, repeatability, mean time to recover — all go up. And the GCP free tier is very generous, if you need more builds you pay for what you use and not a virtual server sitting around (yes we’re so cloud native that we worry about virtual resources now). The consistency of having the local machine steps mirrored by the pipeline, means that we retain full control to debug each step and replay it locally. The last point is 🤔 while we could use Cloud Functions instead of Firebase Functions to future proof compatibility with GCP, we would lose convenience of both secrets and project credentials managed by Firebase to be taken up by Secret Manager, which is more configuration in the pipeline of the project credentials. Ultimately, there are a lot of benefits going with Firebase Functions deployment in GCP which we would not get in other cloud providers.

Gotchas

• ⚠️ 403 Error: Deployment of Functions through Firebase CLI args:['deploy', '--only=functions']requires enabling Service Usage API, but was not documented as a step.

Service Usage API has not been used in project XYZ before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/serviceusage.googleapis.com/overview?project=XYZ then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

> Solution: follow the link to enable Service Usage API…

• ⚠️ 403 Error: Deployment of Functions through Firebase CLI args:['deploy', '--only=functions'] requires extra permissions, but again was not documented as a step. To debug this, I had to use debug args:['deploy', '--debug', '--only=functions']

Missing necessary permission iam.serviceAccounts.actAs for cloud-functions-mixer on the service account your-account@appspot.gserviceaccount.com.\nGrant the role 'roles/iam.serviceAccountUser' to cloud-functions-mixer on the service account your-account@appspot.gserviceaccount.com.\nYou can do that by running 'gcloud iam service-accounts add-iam-policy-binding your-account@appspot.gserviceaccount.com --member=cloud-functions-mixer --role=roles/iam.serviceAccountUser

> Solution: grant permission so that the XX@cloudbuild.gserviceaccount.com has “Service Account User” role

Enable not only “Firebase Admin” but also “Cloud Functions Developer” and “Service Account User” for the Cloud Build’s Service Account. Service Account User has to be also granted in IAM.

• ⚠️ Build error: Logging needs to be specified, if you toggle the preview mode service account.

Your build failed to run: generic::invalid_argument: generic::invalid_argument: if 'build.service_account' is specified, the build must either (a) specify 'build.logs_bucket' (b) use the CLOUD_LOGGING_ONLY logging option, or (c) use the NONE logging option

> Solution: add options.logging: CLOUD_LOGGING_ONLYto cloudbuild.yaml

• ⚠️ Warnings about inadequate delete permissions on storage

Permission 'artifactregistry.packages.delete' denied on resource '//artifactregistry.googleapis.com/projects/xyz/locations/us-central1/repositories/gcf-artifacts/packages/your_package' (or it may not exist).

> Solution: ignore it as this is only warning and does not break the build. Hopefully this gets fixed when the APIs get updated to use Artifact Registry instead of Container Registry, but that’s a problem for another day and isn’t working as yet. However, this warning is noisy and could be a red herring when you really have an issue.

Overall Setup Experience

Errors in GCP are not that straightforward to debug, and when searching stackoverflow, not many others have come across similar issues. This could be due to using a non-documented step (Cloud Build of Firebase Functions). As this is my first time using Cloud Build, I’ll probably get used to it overtime. However, the IAM concept of actAs is confusing. Given that industry established concepts of Roles and Groups already sit on top of User objects to make governance easier, I felt that actAs is Google’s attempt at doing something unnecessary. Does it bring more to the table when we limit the final access to resources? Possibly so, but the responsibility of cloud provider and user is shared with the explicit understanding that access granting is a user responsibility. Furthermore, with RBAC and even ABAC coming along, actAs really seems to be going against the grain here.

Cloud Build docs don’t mention Deploying to Firebase Functions