garbetjie / terraform-google-cloud-run Goto Github PK

https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_service#project

project - (Optional) The ID of the project in which the resource belongs. If it is not provided, the provider project is used.

There are use-cases where the provider project may differ from the target project for the new resource, and unfortunately it's currently not possible to reliably use dynamic providers in terraform. Therefore, it would be great if we could specify which project we wish for the service to be created in.

An additional caveat is that the actor may not have access to the default project associated with their provider. I think the logic would therefore be:

1. Allow a user to specify an explicit project_id
2. If no explicit project_id is provided then obtain the default project for the provider

variable "project_id" {
  type    = string
  default = null 
}

data "google_project" "default" {
  count = var.project_id == null ? 1 : 0
}

locals {
  project_id = var.project_id != null ? var.project_id : data.google_project.default.project_id
}

I'm not a terraform expert so although this works, I'm not sure if it's best practice: perhaps there's a better way to tackle this. If this is the right way, I'm happy to submit a PR.

Ps: great work on this module, looking forward to using it! thank you.

At the moment the module does not allow for the ingress settings to be configured to restrict access to the Cloud Run service.
https://cloud.google.com/run/docs/securing/ingress

I've opened PR #2 to replace the local.service_ingress value for a variable that can be configured.

When running a new plan after initial deployment of Cloud Run, we always get prompted that there is a change due to the annotation: run.googleapis.com/operation-id

Example:

 # module.cloud_run_service["run-service"].google_cloud_run_service.default will be updated in-place
  ~ resource "google_cloud_run_service" "default" {
        id                         = "locations/europe-east1/namespaces/cloud/services/run-service"
        name                       = "run-service"
        # (4 unchanged attributes hidden)

      ~ metadata {
          ~ annotations      = {
              - "run.googleapis.com/operation-id"   = "6abe3bd3-f6e7-4f00-95bb-970c63a34a84" -> null
                # (6 unchanged elements hidden)
            }
            # (6 unchanged attributes hidden)
        }

        # (2 unchanged blocks hidden)
    }

Ideally run.googleapis.com/operation-id would be added to the lifecycle ignore_changes block.

I tried this example:

env = [{ key = "DB_HOST",value = var.database_dns_name },
{ key = "DB_PASS", value = var.schema_pass }]

But i got this error:
Cannot use a tuple value in for_each. An iterable collection is required.

Summary

Creating a new Cloud Run service that uses Secret Manager fails with this error:

╷
│ Error: Error creating Service: googleapi: Error 400: metadata.annotations: Annotation 'run.googleapis.com/secrets' is not supported on resources of kind 'Service'. Supported kinds are: Revision, Execution
│ Details:
│ [
│   {
│     "@type": "type.googleapis.com/google.rpc.BadRequest",
│     "fieldViolations": [
│       {
│         "description": "Annotation 'run.googleapis.com/secrets' is not supported on resources of kind 'Service'. Supported kinds are: Revision, Execution",
│         "field": "metadata.annotations"
│       }
│     ]
│   }
│ ]
│ 
│   with module.cloud_run.google_cloud_run_service.default,
│   on .terraform/modules/cloud_run/main.tf line 2, in resource "google_cloud_run_service" "default":
│    2: resource google_cloud_run_service default {
│ 
╵

I believe this is happening because the run.googleapis.com/secrets annotation is being set in metadata.annotations where it's not supported.

Removing the run.googleapis.com/secrets annotation from here should fix the issue.

Example Code

Terraform to reproduce the error:

variable "project_id" {
  type        = string
  description = "The GCP project ID where the resources will be created."
}

# Create a service account
resource "google_service_account" "this" {
  project      = var.project_id
  account_id   = "my-service-account"
  display_name = "my-service-account"
}

# Create a secret in Secret Manager
resource "google_secret_manager_secret" "secret" {
  project   = var.project_id
  secret_id = "my-secret"
  replication {
    automatic = true
  }
}

# Store the secret value
resource "google_secret_manager_secret_version" "secret" {
  secret      = google_secret_manager_secret.secret.id
  secret_data = "super-secret-value"
}

# Allow the service account to read the secret value from Secret Manager
resource "google_secret_manager_secret_iam_member" "secret" {
  project   = var.project_id
  secret_id = google_secret_manager_secret.secret.secret_id
  role      = "roles/secretmanager.secretAccessor"
  member    = "serviceAccount:${google_service_account.this.email}"
}

module "cloud_run" {
  source = "git::[email protected]:garbetjie/terraform-google-cloud-run.git//?ref=2.2.1"

  project               = var.project_id
  location              = "us-central1"
  name                  = "my-cloud-run"
  image                 = "us-docker.pkg.dev/cloudrun/container/hello"
  service_account_email = google_service_account.this.email

  env = [
    {
      key     = "MY_SECRET"
      secret  = google_secret_manager_secret.secret.id
      version = "latest"
    },
  ]
}

Not sure what I did wrong,
My first run worked on terraform cloud but the 2d one had this strange issue with metadata

Error: Invalid index
on .terraform/modules/my_cloud_run_service/outputs.tf line 7, in output "image":
  value = google_cloud_run_service.default.metadata[0].annotations["client.knative.dev/user-image"]
The given key does not identify an element in this collection value.

At the moment, when the latest version of secrets are exposed through the environment, this value is not updated to reflect the latest version. This will only happen on a cold start, and never if instances are kept warm. This is not an issue when mounting secrets as volumes.

There should be the functionality provided to force a new revision to be (optionally) created if any secrets using the latest version are exposed through environment variables.

Is this something which might be possible in the future or are there any obvious methods I'm missing to implement this with the current plugin?