CODEWITHSUNDEEP
firebasesecuritygoogle-cloud-platformgoogle-cloud-storagecredentials
andremene
andremene

Reputation: 135

Production security for .json private keys in Google Cloud Platform and FireBase

We're developing a full-stack platform deployed on GCP via AppEngine and with Firebase (Firestore + RealTimeDb) as noSql Db Module.

We're going live but I've a doubt. Now we're using the Firebase private-key.json to interface our software to Firebase and it is saved to a folder in the project like src/firebase and it is bound to our code through:

admin.credential.cert(require(path))

The API key and the path are saved to the .env file.

We're using the same technique to use the GCP client libraries (for example like Logging system). I've also see that for GCP client libraries Google advises to use environment variables, but also indicates that they're active only during the session.

Anyway, to respect and to optimize security of our system: we should go live with these configurations or we have to change them? Please, do you have any advice to not expose the credentials and to don't have a vulnerable system?

Thanks guys

Upvotes: 1

Views: 1175

Answers (1)

Farid Shumbar
Farid Shumbar

Reputation: 1420

Posting John Hanley's, guillaume blaquiere's, al-dann's and Alex L's comments as a Community Wiki for visibility.

App Engine and Firebase are different services. There is a difference between their configuration files.

App Engine does not require a service-account.json file. Use Application Default Credentials (ADC). Deploying a service-accout.json file inside your application source code is NOT SECURE.

The AppEngine service has the permission to use Firebase product (Firestore, Firebase functions) which should be sufficient. This means that you don't really need an API Key and a Firebase private key in your Node.js back-end.

App Engine runs under a service account. It may be possible to grant relevant IAM roles to that account (i.e. roles/datastore.user), so it can work with the Firestore service. If you would like - you can keep them in different projects.

You can refer to the Node.js quickstart for guidance in this scenario.

Upvotes: 1

Related Questions