DEV Community

Cover image for Secrets Management w/ Firebase App Hosting and NextJS
Dean Andreakis
Dean Andreakis

Posted on • Originally published at dwa.weblog.lol on

Secrets Management w/ Firebase App Hosting and NextJS

Definition

I am using Firebase App Hosting as a backend for a NextJS app that I am developing. I am also using the Firebase CLI to configure and manage my Firebase project. One of the many challenges along the way was how to manage secrets within the app. Secrets can be anything you determine to be sensitive information such as:

  1. API Keys: Tokens used to authenticate requests to an Application Programming Interface (API). They grant access to services and should be kept confidential.

  2. Passwords: Credentials used for user authentication to access systems or services. These should be stored securely, usually hashed.

  3. Private Keys: Cryptographic keys used for encryption, signing, or authentication processes. These should be kept confidential at all times.

  4. Encryption Keys: Keys used to encrypt and decrypt data. These must be securely stored to prevent unauthorized access to sensitive data.

  5. Access Tokens: Tokens that grant access to specific resources or systems, often used in OAuth and other authentication protocols.

  6. Database Credentials: Usernames and passwords used to connect to databases. These should be kept secure to prevent unauthorized database access.

  7. Certificates: Digital certificates that authenticate the identity of systems and encrypt data. Private certificates should be kept secret.

  8. SSH Keys: Used for secure shell (SSH) access to servers. The private SSH key should remain confidential to ensure secure server access.

  9. Webhooks Secrets: Tokens or keys used to validate and secure webhooks communication.

  10. Personal Identifiable Information (PII): When it's part of the application code or logs, it's considered sensitive.

Problem

Common best-practice is to not commit secrets to a repository and instead use a method to allow for referencing of the secret in production that does not reveal the actual secret value.

It is common during development to put secrets in a local environment file that is not committed to a repository. One way to do this is to include a reference to the environment file in the .gitignore file of the project. This method is less than ideal during production as the environment file containing the secrets would have to be managed outside of git (or whatever configuration management tool used).

Solution

The solution for production is to use the Secret Manager service that is part of Google Cloud Platform. If you login to the GCP console and search for "Secret Manager" you should see something similar to the below screenshot:

GCP Secret Manager

Click on "Create Secret" and it should take you to a page where you can add the necessary information as seen below: Add a new secret

Once you add a new secret in the GCP secret manager then you can go back to your project directory and enter the following command in a terminal using the firebase cli tool:

firebase apphosting:secrets:grantaccess -b <firebase-project-backend-name> <name-of secret>
Enter fullscreen mode Exit fullscreen mode

Lastly, you can then add a reference to the secret in your projects apphosting.yaml file:

env:
  - variable: <name referenced by your code>
    secret: <name of secret from GCP secret manager>
Enter fullscreen mode Exit fullscreen mode

Your code can now reference the secret as follows:

const secret = process.env.<name-of-secret>
Enter fullscreen mode Exit fullscreen mode

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay