We've been seing some sudden strange behaviour of our service account in Google Cloud console these past few days. We're using this service account to authenticate our API with Firebase SDK - and without any warnings the usage of this account just drops to zero (see attached screenshot).
There are no warnings from Firebase SDK telling us that the service account is no longer valid, and in fact the service account is stated as "active" in the cloud console. From Firebase SDK logs we're actually seing the read/writes be completed, but they are not actual performed when viewing the data in Firebase console, which is why I expect the problem to be within the service account.
The temporarily solution has been to create a new service account and upload the associated key to our API. Then it starts working again without any additional actions required, but suddenly the usage drops to zero after 12hours++.
There are no alarms in Google Cloud Console and billing is activated with status OK.
Since the Firebase logs tells us "everything is OK", and Google Cloud console does not show any warnings, I don't understand where the problem might be. Anyone experienced something similar, and could point me in the right direction? Any help is much appreciated!
Metric graph of service account usage
Related
We are getting this error message when publishing app update:
Your app contains exposed Google Cloud Platform (GCP) API keys. Please see this Google Help Centre article for details.
I can follow the instructions and restrict the API Key for Android App by entering package name and SHA-1 certificate fingerprint, but my question is will this somehow affect Google Sign In as the app is available to production.
Like for instance any issues through logging in or something ?
Still haven't tried to perform the instructions due to concerns that it might prevent Google Sign In from working
I have a Node.js API (built with Express.js) hosted on Firebase Cloud Functions and an accompanying web application hosted on Firebase Hosting which is supposed to interact with the aforementioned API.
I would like to restrict calls to the API so that only the web application would be able to call the cloud functions. How can I achieve that?
What I have tried:
using the App Check or more precisely Google's reCAPTCHA v3 for web apps. I have whitelisted the domain of the web application and have activated App Check token validation server side as well. The problem with App Check, however, is that I am able to obtain the reCAPTCHA attestation token from the browser (after authenticating through the web app) and use that with requests made from anywhere. This enables bombarding the API from outside the web application and defeats the purpose of using App Check in the first place.
Something to note here, the documentation for activating App Check in Cloud Functions instructs the usage of functions.https.onCall(). However, since my API is built using Express.js, I had to use a workaround to be able to use functions.https.onRequest() as instructed here.
restricting the Cloud Function from Google Cloud console to allow only clients of the same project to call the function as instructed here. Unfortunately, my web application hosted on Firebase Hosting does not seem to belong under the same Google Cloud project. Apps hosted on Firebase Hosting do not appear in Google Cloud console. Furthermore, after adjusting the Ingress settings of the functions to "allow internal traffic only", I am receiving CORS errors when attempting to access the API through the web application. I am unable to access the API from anywhere else though, which is partly the desired outcome.
Before anyone proposes limiting the domains in CORS options from within the API, while this might serve the purpose of restricting access to the API endpoints, it still would allow calling the function rapidly and thus, potentially, racking up the bill.
I am grateful for any suggestions!
Firebaser here.
This is a great question! Doug has already made some great points above, and I'll just add to that by saying that the TTL on App Check tokens reduce the replay window that you observed in your first bullet point, and this TTL is configurable.
The default TTL for reCAPTCHA v3 is 1 day to protect against running out of quota, but you can set a shorter TTL to increase the cost for an attacker trying to set up a replay attack. But please do be mindful of the associated trade-offs as described in the documentation. You can read about the associated quotas and limits here.
Unfortunately, web applications redirected from Firebase Hosting can't hook up to the GCP internal network. App Check is actually exactly what you are looking for in this situation.
Finally, because we are continuously working on improving the App Check platform, the comments you leave here are valuable for us as we decide on what anti-abuse features we want to work on next.
Have an old iOS & Android app that uses Firebase to authenticate & Firestore as a back end.
I just want to shut it down. i.e. stop authentication & Firestore access.
I know that's not polite but the app is causing real problems for other apps in the project.
Thought Google support: Delete Firebase App sounded promising but reading the documentation it seems like this doesn't do much more than stop the collection of analytic data - which doesn't sound like app removal at all.
Was hoping for something more dramatic but am reticent to try as removal is a one-way street.
I removed the app's OAuth clients in the Google APIs console credentials page but that didn’t have any effect on signing up, signing in ...which also seems weird.
So, would appreciate if anybody could shed more light on what removing an iOS & Android app from a Firebase project really does?
Thanks in advance
Removing the App from your Firebase project removes the credentials available to apps that may wish to log in and use your project's services, being Firestore, Realtime DB, Cloud Functions, FCM, etc . This does not disable or remove the functionality within your app client which would throw errors when the app credentials are invalid.
I realized that my service account credentials were posted to github so I decommissioned them and now I am no longer able to update my firebase functions.
This is the error I get:
functions: failed to create function functionName
HTTP Error: 400, Default service account '<APP_ID>#appspot.gserviceaccount.com' doesn't exist. Please recreate this account (for example by disabling and enabling the Cloud Functions API), or specify a different account.
I've tried numerous solutions to no avail.
disabling and enabling the Cloud Functions API
re initializing the sdk - using a newly generated service account. The firebase cli seems to still be using the old account which no longer exists.
I've contacted firebase support who suggested the second solution above and have been entirely unresponsive for days.
In case anyone has a similar issue I figured out how to fix it:
The key that was leaked was created here:
I assumed that I had to delete the entire account once that key was leaked, and didn't realize I could just delete that key from the same page:
Because I deleted the service account less than 30 days ago I was able to Restore the default service account
If you are outside of the 30-day window I don't think anyone can help you.
Since migration to V2 logs from Cloud ML jobs are not accessible on the Stackdriver logging console anymore. The last log displayed is
Waiting for Tensorflow to start.
The job is executed and completed successfully, I just can't access outputs in the logs
All Stackdriver APIs are enabled for the project.
There are no known issues with Cloud ML's Stackdriver logging. The fact that you see "Waiting for Tensorflow to start." indicates you are seeing log messages from Cloud ML.
If logs from your Python/TensorFlow program are missing that usually indicates Cloud ML hasn't been authorized to send logs to Stackdriver logging for your project. To check permissions do the following
Identify the Cloud ML service account by following these instructions
In the Cloud Console select the IAM Tab
Verify that the Cloud ML service account is listed and has Logs Writer permissions
This problem also took me two weeks to search answers online with frustration, until I came across this post. I did not see "migration to V2" as OP mentions but I simply could not get any application logs in StackDriver, only system logs of job started/completed. Following what Jeremy replies solves the problem.
To make Jeremy's reply simpler to follow, essentially you add the ML service account
cloud-ml-service#<project-id>.iam.gserviceaccount.com
to your project's IAM members, with at least "Logs Writer" role.
You can get "project-id" by:
gcloud config list project --format "value(core.project)"
I also assigned Project->Editor role to allow Bucket access.