I'm using two firebase projects: one for development and staging, and another for production. The Firebase CLI allows me to switch projects with firebase use _____.
For the client I'm using create-react-app and implicitly configuring firebase by using the From Hosting URLs.
The trouble comes with configuring each project's connection to third party services. For most services I have separate accounts, so need different keys (and secrets on the server), for development and production.
For firebase functions, I can use functions config vars for each project. Pretty easy.
But what's the best way to do this on the client?
create-react-app has great support for various .env files, but can I link a .env file to a firebase project rather than using their prioritization?
Or is there a way to expose the firebase functions config vars to create-react-app's start, build, and test processes as environment variables? (preferably without building all variables into the public js :-P)
What's the best way to do this?
The best way to do this seems to be to use GCP secret manager :
Secret Manager stores API keys, passwords, certificates, and other
sensitive data. It provides convenience while improving security
https://cloud.google.com/secret-manager/docs/quickstart
Beware, it's a standalone service by GCP, therefore Google charges you to store your API keys. The pricing calculation example they detail, so i'm guessing it's a typical use case, gives a monthly cost of $15.15.
That's not cheap to store dumb API keys.
The other way is to use cloud functions as you did.
The benefits of using GCP SM are that the service can be combined with audit logs, that it has a version management feature, and that you can set permission levels.
Related
I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
I need to create Firebase projects, get the Admin SDK private keys, and add resources programmatically.
I can create projects with CLI - firebase projects:create. But after that to use Admin SDK or REST API to add resources to the project, I need to get Admin SDK private key.
My plan is web scraping with direct HTTP requests. I know Fastlane use same logic to control Apple Developer Portal UI and fetch data from it programmatically.
First, I need to go: https://console.firebase.google.com/project/<project_id>/settings/serviceaccounts/adminsdk with required cookies, headers etc.
Then, I should mimic the Generate new Private Key button below and get the private key.
But I have never used this method, especially with a web page that contaions sessions, cookies etc. And, I want to build it as a microservice and deploy to a server. So, I believe 2FA might be a problem.
My questions:
Is there any more cost-effective way to get Admin SDK? Maybe, I am missing some feature in Firebase resources.
Can I mimic this button's behaviour without using any front-end scraping? Is there any precautions in Firebase servers to prevent this kind of solution.
If I do it in this way and deploy to a server, would 2FA be a problem? Can microservice work with 1-month valid sessions? Or, would it asks 2FA all the time that it works? (I have never used headless browsers etc. I just some basic web-scraping experience with Selenium.)
It looks like scraping is not necessary, gcloud CLI do the job. If you want to create Firebase projects and get service accounts programmatically do the steps below:
Create with firebase CLI: firebase projects:create --display-name "<project-name>" <project-id> (Or, probably you can create with gcloud CLI as well)
Change active project in gcloud CLI with gcloud config set project <project-id>
gcloud iam service-accounts list and store the EMAIL here. (There is just automatically created service account here, no private key created.)
Create and store the private key: gcloud iam service-accounts keys create key.json --iam-account= <EMAIL-you-stored>
I have to build an API using Firebase, and need some help with design choices. I want to be able to sell the API to users, who can then use it to build/integrate their own applications. Users will have both read and write privileges.
General information:
I'm using Firestore db with email & password authentication.
Only specifically assigned users may use the API
Each user may only access specific documents concerning them.
I've noticed 3 different ways in which an API can be provided to a user of my Firestore db:
https triggered cloud functions (https://firebase.google.com/docs/functions/http-events)
Using the SDK (https://firebase.google.com/docs/firestore/client/libraries)
Using the REST API provided by Firbase (https://firebase.google.com/docs/firestore/use-rest-api)
API requirements:
Used only by users that I specifically grant access to (email & password login)
I want to limit these users to only a couple of read/write tasks that they're able to perform.
It needs to be safe.
My current approach is:
Use the 3rd option - the REST API provided by Firebase (thereby giving users the projectId and API key)
Add authorised users to the list of authorised accounts on Firbase, and limit access using custom claims and database rules.
My questions:
It seems that https functions (option 1) are normally used in API building. Are options 2 and 3 unsafe?
What are the normal use cases of the 3 options? When should each be used and when should each be avoided?
Are there any obvious flaws in my choice of option 3?
Any other useful information about making these design decisions will be much appreciated.
Thank you in advance
TL;DL: It depends on what you want to do with this API and how many and what type of devices/users will be calling it.
Before answering your questions I will list below the advantages of each approach:
Cloud Functions:
Cloud Function is a Functions as a Service Solution, so it's also a hosting service for your API, therefore you won't have to provision, manage, or upgrade servers and the API will automatically scale based on the load. Also this option takes into account the pros of SDKs and client libraries, since your code will have to use it to connect to Firestore anyway.
SDKs and client libraries:
This is the easiest and more optimized way to reach Firestore, however, environments where running a native library is not possible such as IOT devices will be left out of your solution, so consider this while implementing this option.
Cloud Firestore REST API:
Every device properly authorized to access Firestore will be able to do so.
NOTE: For both SDK and REST API you will need to consider hosting of your API, either on Cloud Functions, as mentioned, App Engine Standard, App Engine Flex or a Compute Engine Server Instance.
All that being said, it's up to you and your API's usage and requirements to say which option is best considering the points above.
As per security, I'd say that all option can be secure if firebase rules and firebase auth are set correctly.
This page explains both:
Obtaining and providing service account credentials manually for developing local, deploying on-premises, or deploying to another public cloud.
Obtaining credentials on Compute Engine, Kubernetes Engine, App Engine flexible environment, and Cloud Functions
But there is no mention of obtaining credentials on Cloud Run. I'd appreciate it if you give instructions for obtaining credentials and setting firebase-admin initializeApp and firebase initializeApp for authentication on Cloud Run.
The documentation suggests that you can use the default service account just like other Google Cloud products as described here. The Firebase Admin SDK should use that account when initialized with no parameters.
There are also steps described if you want to use a non-default service account, which you can simply configure in the console or provide with gcloud.
If you must provide a file that's readable at runtime, you will have to deploy an image with that file added to the image. There is no short set of steps to add that file - you will have to make your docker build include it in a readable location, and your code will know where to look for it in order to load it.
I am transitioning a Heroku-hosted ReactJS/NodeJS application to be hosted on Firebase. Because Firebase only handles static pages I need to reconfigure how my private environmental-specific variables for Development, Staging, Production environments are configured. For example before I defined these sorts of variables:
CLIENT_ID=secret_here
DOMAIN=secret_here
REDIRECT_URI=secret_here
upon the Heroku environment I was deploying to and now I must set them into firebase functions environments from the Firebase CLI for Dev, Staging and Production.
Firebase has documentation on adding environmental configurations to Firebase Functions such that I can add key/value pairs to be accessed at runtime from within a firebase function:
firebase functions:config:set mySecret.key="CLIENT_ID" mySecret.id="secret_here"
however I am unclear how added configuration variables can be accessed from Firebase-hosted static applications (rather than functions).
Is it as simple as simply referencing the firebase functions library from my application and retrieving the defined key from within my application (like so)?
const functions = require('firebase-functions');
...
functions.config().auth0.CLIENT_ID
The variables you define through the link you provided are only available via Cloud Functions. They're not made available directly to the static content served by Firebase Hosting.
If you want, you can make an HTTP function that does nothing but return the JSON from your env vars, and call that from your web content. Bear in mind that you're exposing your secret keys to the world.
The best practice way to handle what I am trying to do is to refactor all of the application logic requiring environment configuration into firebase functions. I can then invoke said functions to reference environment config and execute the code consuming them. This is the answer/solution I needed and didn't have the context to realize earlier. thanks for edging me towards that realization.