How can I practically use firebase emulators and deploy previews in GitHub actions if PRs from forks can't access secrets?

Question

I use Firebase secrets for two things in my GitHub Actions workflow:

1. FIREBASE_TOKEN to run tests with the hosting emulators. The docs say "The token should be treated like a password; make sure it is kept secret."
2. firebaseServiceAccount to deploy after the build succeeds. Pushing to the master branch deploys the code to the production site, while in a PR it deploys a preview. The action README says "It's important to store this token as an encrypted secret to prevent unintended access to your Firebase project. Set it in the "Secrets" area of your repository settings"

The problem is that when an external contributor makes a PR from a fork, the build doesn't have access to those secrets. That means that GitHub actions can't run tests on the code in the PR, and even if it could, it couldn't deploy a preview.

I understand that GitHub can't magically make these secrets available to the workflow without risking exposing them to arbitrary malicious code. But I can't understand how Firebase intends for these features to be used in practice. Builds not working for external contributors seems like a serious limitation in an open source project. I can't imagine that I'm supposed to add every person who opens a PR as a GitHub collaborator. That sounds very dangerous for security - I only want to do that after having some time to build trust.

So I have a question for each secret and use case. The questions are different, so I can post a second question if people want, but you can see how they're closely related.

1. Running tests with emulators, i.e. specifically not against a live environment, seems like precisely the kind of thing that shouldn't require a special secret token. Why is this required? What would be the consequences of making FIREBASE_TOKEN publicly available?
2. Can I make a service account that only has permission to deploy preview channels, but not 'live'? If so, would there still be risks to making that service account public? Can people abuse the account in a way that I would have to pay for?

Answer 1

I'm not an expert on GitHub Actions and shared secrets (especially in the context of a public/open-source repo), but this is how I would approach it.

As you say, both the FIREBASE_TOKEN and firebaseServiceAccount grant highly critical access to your project.

I would therefore approach it by having two different Firebase projects: one for the production/live code, of which secrets (auth and service account tokens) are private to you, and another project for the preview/staging environments (and dev too via the emulators). This way you would definitely get a service account key that is separate from the production one. As for the FIREBASE_TOKEN, since I believe it's tied to your account, I think you could add a collaborator to the "dev/staging" Firebase project and get the token specifically for that project.

I think the 2 projects setup ("dev+staging" and "production") on Firebase is quite common and I've seen it recommended multiple times.