Why You Should Use Firebase Functions With A Service Account

<code>firebase-tools</code> is a popular library built by Google providing abstractions to develop and deploy <a href="https://firebase.google.com/" rel="noopener ugc nofollow" target="_blank">Firebase</a> applications. <code>firebase-tools</code> is the recommended way for deploying serverless functions to Firebase / Google Cloud. Firebase is a service built <a href="https://firebase.google.com/firebase-and-gcp/" rel="noopener ugc nofollow" target="_blank">on top of</a> Google’s cloud platform. <blockquote> The Firebase Command Line Interface (CLI) Tools can be used to test, manage, and deploy your Firebase project from the command line. Deploy code and assets to your Firebase projects Run a local web server for your Firebase Hosting site Interact with data in your Firebase database Import/Export users into/from Firebase Auth Source: <a href="https://www.npmjs.com/package/firebase-tools" rel="noopener ugc nofollow" target="_blank">firebase-tools — npm (npmjs.com)</a> </blockquote> I have used Firebase for about two years to develop a web application. A while back, I also started using native Google Cloud features like <a href="https://cloud.google.com/secret-manager" rel="noopener ugc nofollow" target="_blank">Secret Manager</a> to store secrets directly in the cloud. And precisely, the usage of Secret Manager should reveal a fatal flaw in the standard setup of <code>firebase-tools</code> and, more specifically, how Firebase recommends authenticating on personal and CI/CD environments. <h1>What Happened?</h1> It all started while setting up a new non-production stage for my application. I created a new Google Cloud Project (GCP), new service accounts, new secrets, etc., only to discover afterward my CI/CD jobs on GitHub were failing. It was failing during testing and thus even before the deployment to the new stage. <a href="https://betterprogramming.pub/why-you-should-use-firebase-functions-with-a-service-account-1e62028c94cc">Read More</a>