Change method of deploying cloud funcs

[vincerubinetti]

Changes the method of deploying cloud funcs to align with CU OIT's preferred permissions setup for GCP, which forces us to do the deployment through a script with the GCP CLI instead of through the web console UI (where it is currently impossible to specify separate service accounts for the build and runtime). As I mention in this comment on PR #62, we're still not doing automatic deployment of this script (yet) since it's very small and unlikely to change.

@jananiravi You'll see in this diff that a GITHUB_TOKEN is required so that an issue can be created on this repo. It also determines what account the issues will be created by. There are basically three methods we can choose from:

1. You, as the @jananiravi username, generate a fine-grain personal access token (PAT) that only has permissions to create issues, and only on this repo. The feedback form would then create issues as if you had created them.
2. We create a new GitHub user like @molevolvr-bot, keep track of its login info, and generate a PAT with that. The feedback form would then create issues as the bot account, which we could give a little 🤖 avatar so people know it was automated.
3. We make a GitHub App. The feedback form would then create issues as the App.

1 isn't ideal because your username will get much more notifications (which maybe you want), and it's unclear at first glance (other than the feedback label that will be auto-added to the created issue) that it was an automated thing.

3 is imo overkill for what we are trying to do. It involves more set up, more secrets, and a more involved auth handshake than what we currently have in the /feedback/index.js script. Apps allow more complex things like allowing multiple repos to install it, multiple users to authenticate with it, and acting on behalf of users, when all we really need is issue write permissions for a single repo.

Therefore, I recommend option 2. If you're agreeable to that, I can create it, add its username/password to the software team's vault, share it with you so you have ownership access, and do the deploy with its PAT.

Gemini's summary of the benefits of making a GitHub app, with my own commentary

Granular Permissions and Security:
• GitHub Apps have their own independent permissions, allowing for highly specific access control to resources without granting broad user-level permissions.

Fine-grained personal access token's alleviate this. They allow, for example, only the ability to write issues to a specific repo.

• They utilize short-lived installation access tokens, reducing the risk window if a token is compromised, unlike PATs which can be long-lived and grant broader access if leaked.
• Permissions are associated with the app installation, not a specific user, ensuring continued functionality even if a user's access changes.

PATs can be leaked. However we have the .env.local file where ours is supposed to be added in .gitignore, and we have GitHub's built-in push secret protection enabled, and if a PAT happens to be committed, we can revoke it immediately.

Scalability and Management:
• GitHub Apps are designed for integrations and services that need to interact with multiple repositories or organizations.
• They can be installed on organizations and repositories, providing a centralized way to manage access for automation and tools across a team or company.
• The lifecycle of a GitHub App is separate from individual users, making it more robust for organizational automation.

We don't need this.

Dedicated Identity:
• GitHub Apps act as "service accounts," operating with their own identity on GitHub, distinct from any individual user.
• They do not consume a GitHub seat within an organization.

Option 2 allows us to have a "bot" identity for these cloud functions.

[netlify]

✅ Deploy Preview for molevolvr ready!

Name	Link
🔨 Latest commit	5bf66d9
🔍 Latest deploy log	https://app.netlify.com/projects/molevolvr/deploys/689cfb1c9f8256000887b27c
😎 Deploy Preview	https://deploy-preview-63--molevolvr.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[vincerubinetti]

Leaving this here for posterity.

This is John Finigan's Terraform for the Google Cloud project, which basically describes the permissions/roles he needed to give to each service account within the project to make everything work as expected. This goes hand-in-hand with the content of the deploy.sh script in this PR, where we build the cloud function with a "builder" service account, and run it with another, and each service account gets as minimal amount of permissions as possible.

resource "google_service_account" "cloudrunfunc-sa" {                                                
  account_id = each.key
  project    = module.som-dbmi-strchive-app.project_id
  for_each   = toset(["cloudrunfunction-builder", "cloudrunfunction-runtime"])
}

resource "google_project_iam_member" "cloudrunfunction-builder-iam" {
  for_each = toset([
    "roles/logging.logWriter",
    "roles/monitoring.metricWriter",
    "roles/storage.objectViewer",
    "roles/run.builder",
  ])  
  project = module.som-dbmi-strchive-app.project_id
  role    = each.key
  member  = google_service_account.cloudrunfunc-sa["cloudrunfunction-builder"].member
}

resource "google_project_iam_member" "cloudrunfunction-runtime-iam" {
  for_each = toset([
    "roles/logging.logWriter",
    "roles/monitoring.metricWriter",
  ])  
  project = module.som-dbmi-strchive-app.project_id
  role    = each.key
  member  = google_service_account.cloudrunfunc-sa["cloudrunfunction-runtime"].member
}

[vincerubinetti]

We ended up going with option 2 above, creating the molevolvr-bot account (username and PW saved in the SET vault).

Configuring it with the right permissions was a little trickier than expected, see this comment. In summary:

1. Make sure Allow access via fine-grained personal access tokens is enabled in the org-wide settings
2. Make sure the account trying to create the token is a member of the org that owns the repo
3. When creating the token, select the org, not the username, in the Resource owner dropdown