0
votes

I'm currently working on a project that will automatically set up a new Firebase/Gcloud project. It relies heavily on the Firebase CLI and gcloud SDK with user credentials for several mandatory steps.

I am now trying to move this project to a Docker container on Cloud Run. I have been able to authenticate the Firebase CLI with user credentials using their built-in token-based CI command.

I would like to ask if it's possible to authenticate the gcloud SDK using a similar method.

Why service accounts probably won't work

I realize that service-to-service programs like this should be authenticated with service accounts. In my case, however, the flow of the program goes like this:

  1. Use Firebase CLI to create a new gcloud/firebase project
  2. Use gcloud SDK to add IAM-bindings, enable APIs, billing, etc. for the new project

I am unable to use a service account to authenticate the requests in step 2 as the project has only just been created and I therefore haven't yet had the opportunity to give any service accounts permission to edit it or download the key-files. This is why I'd like to authenticate with a token representing user credentials.

By default, the Cloud Run environment actually has access to a service account for the project hosting the container. Since this service account doesn't have permission to edit the newly created project, using it for authenticating is pointless.

Ideas so far

  1. gcloud auth login --no-launch-browser - Requires user interaction and the key that is provided seems to be unique per login session
  2. Since the Firebase CLI is authenticated with user credentials, maybe there's a way to use that to authenticate the gcloud SDK?
  3. Would it be possible to let a service account inherit all permissions from a user? I have seen a couple of examples of this, but they only work on a per-project level. I realize how unseemly this solution would be.
  4. The gcloud SDK seems to save user credentials in the /root/.config/gcloud folder. I went against all sensible logic and copied this folder over when setting up my Docker-container. This actually works, when I run it on a local Docker container, but when I run it on Cloud Run, the default service account seems to override all other credentials. A local Docker container can access the copied configurations, but even though the files are copied successfully, the gcloud SDK doesn't seem to recognize them.

EDIT: My intentions are to allow less tech-savvy colleges to create a new Firebase project with a large set of pre-defined settings via the click of a button. This includes the following steps:

  1. Set up a new Firebase project (which automatically sets up a new Google Cloud project)
  2. Enable billing
  3. Set user IAM roles and upgrade/download service accounts
  4. Add Google Analytics
  5. Add Cloud storage
  6. Create new Cloud storage bucket
  7. Add Firestore Native mode
  8. Copy pre-defined cloud functions and security roles and deploy them to the cloud

The created Google Cloud project must be a part of our Google Cloud organization. The owner of the project is not important as I manually set IAM roles after creation.

All of the above steps work on my local system and when I use idea #4, they also work on a generic docker container outside of Cloud Run. The problems I'm dealing with is authenticating the request for step #2 and step #3. As both of these requests deal with the newly created project, the default service identity for Cloud Run can't have the required roles to authenticate these requests at this time. This is why I am looking for a way to authenticate via the same user credentials used in step #1 by the Firebase CLI, as those credentials will have owner privileges by default.

1

1 Answers

1
votes

I'm not sure that what you want to achieve is possible. And even if a hack is possible, you don't know if a day it will be broken because of version update or API change.

In addition, using a personal account into an app running on a VM is not a good idea. The log will trace you as user and not the app identity (the service account). What are your personal actions (on your computer and your access to the Cloud) and the app actions (those perform on behalf of you)?

If your concern is about the deployment, you can have a look to terraform or you can even script you own deployment.

I'm not sure to have caught all your blockers and problems, tell us more, maybe there is good workaround!!