`google_firebase_web_app` is creating the default API Key even though a custom `api_key_id` is supplied

[BenJackGill]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.7.0 on darwin_arm64

• provider registry.terraform.io/hashicorp/google v5.12.0
• provider registry.terraform.io/hashicorp/google-beta v5.12.0
• provider registry.terraform.io/hashicorp/random v3.6.0
• provider registry.terraform.io/integrations/github v5.44.0

Affected Resource(s)

• google_firebase_web_app

Terraform Configuration Files

resource "google_apikeys_key" "firebase_web_browser_api_key" {
  provider     = google
  project      = var.project_id
  name         = "key-${random_id.key_suffix.hex}"
  display_name = "Custom Firebase Web Browser API Key"

  restrictions {
    browser_key_restrictions {
      allowed_referrers = ["https://${var.domain}"]
    }

    dynamic "api_targets" {
      for_each = [
        "firebase.googleapis.com",
        "firestore.googleapis.com"
      ]
      content {
        service = api_targets.value
      }
    }
  }
}

resource "google_firebase_web_app" "main" {
  provider     = google-beta
  project      = var.project_id
  display_name = "Web App"
  api_key_id   = google_apikeys_key.firebase_web_browser_api_key.uid

  deletion_policy = "DELETE"

  depends_on = [
    google_firebase_project.main,
  ]
}

Debug Output

Debug output file as a gist.

Expected Behavior

It should use the custom key during the creation of the web app, and therefore not create the default key named "Browser key (auto created by Firebase)".

Actual Behavior

It creates both the custom key and the default key.

Steps to Reproduce

1. terraform apply
2. Check the Google Cloud Console under APIs and Services > Credentials
3. You will see it created the custom key (correct) and also the default key (this should not happen)

References

• Terraform doc for google_firebase_web_app: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/firebase_web_app

[edwardmedia]

@BenJackGill

1) from the log I do not see POST requests which are supposed to create the resources. Not sure how you did tf apply the config.

2) applying the example here, I do see the api key being created but not see the default key in the console. Is it possible the default key was created in a different way? Can you try to apply the example after deleting the default key?

[BenJackGill]

Sorry it's my first time supplying terraform debug logs. Here is an updated gist with new debug logs based on a fresh project. It should be correct now.

Also here is the exact terraform code I am using. As far as I can tell it follows the examples. My original post excluded some parts for brevity but I think it's functionally the same:

# Generates random id for the "name" field of the Firebase Web Browser API Key created below
resource "random_id" "key_suffix" {
  byte_length = 8
}

# Create the Firebase Web Browser API Key and restrict it by domain and all the APIs it uses
resource "google_apikeys_key" "firebase_web_browser_api_key" {
  provider     = google
  project      = var.project_id
  name         = "key-${random_id.key_suffix.hex}" # Used as a uuid by Google. Must be a unique value. Should be random so we don't get errors when deleteing and then re-creating keys, full details here: https://github.com/hashicorp/terraform-provider-google/issues/11726
  display_name = "Firebase Web Browser API Key"

  restrictions {
    browser_key_restrictions {
      allowed_referrers = ["https://${var.domain}"]
    }

    dynamic "api_targets" {
      for_each = [
        "firestore.googleapis.com", # Google Cloud Firestore API
        # "cloudbilling.googleapis.com", # Cloud Billing API
        # "cloudresourcemanager.googleapis.com", # Cloud Resource Manager API
        # "firebase.googleapis.com", # Firebase Management API
        # "serviceusage.googleapis.com", # Service Usage API
        # "identitytoolkit.googleapis.com", # Identity Toolkit API
        # "firebaserules.googleapis.com", # Firebase Rules API
        # "firebasestorage.googleapis.com", # Cloud Storage for Firebase API
        # "storage.googleapis.com", # Cloud Storage API
        # "cloudfunctions.googleapis.com", # Cloud Functions API
        # "apigateway.googleapis.com", # API Gateway API
        # "maps-backend.googleapis.com", # Maps JavaScript API
        # "places.googleapis.com" # Places API (the new Places API currently named as "Places API (New)"" in GCP)
      ]
      content {
        service = api_targets.value
      }
    }
  }
}

# Creates a Firebase Web App in the new project using the Browser API Key created above
resource "google_firebase_web_app" "main" {
  provider     = google-beta
  project      = var.project_id
  display_name = "Web"
  api_key_id   = google_apikeys_key.firebase_web_browser_api_key.uid

  # The other App types (Android and Apple) use "DELETE" by default.
  # Web apps don't use "DELETE" by default due to backward-compatibility.
  deletion_policy = "DELETE"

  # Wait for Firebase to be enabled in the Google Cloud project before creating this App.
  depends_on = [
    google_firebase_project.main,
  ]
}

[edwardmedia]

@BenJackGill I see the apiKeyId being successfully assigned to the webapp in the log you provided

---[ RESPONSE ]--------------------------------------
{
  "name": "operations/workflows/NjRkMzk3MTItNDhiYS00NTY4LWJmYTktYTFmYzVlNDYxNmNj",
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.firebase.service.v1beta1.WebApp",
    "name": "projects/cupcake-ga2n2/webApps/1:270858705069:web:9c5956485f60b59bf40e24",
    "appId": "1:270858705069:web:9c5956485f60b59bf40e24",
    "displayName": "Web",
    "projectId": "cupcake-ga2n2",
    "webId": "YmRkZGQ1MWMtMTJlMi00MmNmLTg4ZGItYWFmOTA0NDY4Njc0",
    "apiKeyId": "ead7b28e-b14e-4f97-8379-eb7adaf932cd",   <--- here
    "state": "ACTIVE",
    "expireTime": "1970-01-01T00:00:00Z",
    "etag": "1_da01a152-0d9d-4844-bdd0-d7ca8afd1bc2"
  }
}

What makes you see wrong with the default API Key?

[BenJackGill]

The custom API key is assigned correctly but when I check the console (APIs and Services > Credentials) I can see that it also creates the default key named "Browser key (auto created by Firebase)". The default key should only be created if there is no custom key.

The Terraform docs say this:

If apiKeyId is not set during creation, then Firebase automatically associates an apiKeyId with the WebApp. This auto-associated key may be an existing valid key or, if no valid key exists, a new one will be provisioned.

Since I am setting a custom key I was surprised to see that the default key was also provisioned. I believe this to be a bug.

Here are the two keys that were created:

1) The custom key.

• Name: Firebase Web Browser API Key.
• API Key: AIzaSyA38TbUSCGkvm1_F4_vB3NZ4w8mAq4mLyM.
• I think this is the key you correctly identified in your previous post.

2) The default key

• Name: Browser key (auto created by Firebase).
• API Key: AIzaSyAefbtRO27SJzwzBznW93m22Qv7KePgT4E.
• This is normally only created when no custom key is provided. Since I am providing a custom key I did not expect to have this default key also created.

See Console pic here:

[edwardmedia]

@BenJackGill oh I see what you meant. I have the same Browser key being created. I think it was created by the api possibly when the Firebase was enabled. There is little the provider can do with it. Does it impact how your app works?

[BenJackGill]

I am trying to secure my apps and it's confusing to see it there. Future devs could end up using that unsecured default key instead of the custom key that I have restricted.

There also doesn't seems to be a Terraform way of searching for a key named Browser key (auto created by Firebase) and deleting it, which would have been a possible workaround to this issue.

[edwardmedia]

@BenJackGill I can't say how the api uses this key. But to manage it, there are two ways

1. Terraform: you can first import the key and then you can manage it in a terraform way
2. api call via curl. Here is the instruction you may want to review.

[edwardmedia]

@BenJackGill let me know if you still need assistance on this matter. Otherwise, I am going to close it soon

[rainshen49]

@BenJackGill The Browser key (auto created by Firebase) is created when the Firebase project is created, not when the web app is created. You should be able to see the key without even creating a web app. This auto-provisioned API key is needed for legacy use cases, and the team is working on a better alternative. However, for your specific case:

1. Delete Browser key (auto created by Firebase) in the Cloud console (unfortunately no clean way to do it in Terraform), you may have to resort to an HTTP request.
2. Make sure all future web apps created in the project uses an api_key_id you supplied.

This together should prevent the auto-creation of the default API key.

[BenJackGill]

Sorry for the late reply. Appreciate your work on this.

From a quick look I think I can use the REST API for API Keys with the list method to get all the keys in a project and then iterate over the list to find a matching display name of the key I want to delete (Browser key (auto created by Firebase)). If a matching key is found in the list, then use the delete method to delete the key.

A little cumbersome but it should work for now until this gets sorted.

[edwardmedia]

@BenJackGill Glad you have a solution for your use case. Closing this issue now

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.