Resolving Terraform deprecation warnings for GCP WIF integrations while maintaining granular project settings

Applicability

Description

When managing GCP integrations via Terraform, a user may encounter a deprecation warning during a terraform plan or apply. This occurs when the configuration utilises the older project_wif_configs block to establish Workload Identity Federation.

The warning typically appears as follows: 

Warning: Argument is deprecated... Please use workload_identity_federation_config with projects instead project specific project_wif_configs.

While the standard documentation often suggests a single integration resource containing a list of multiple project IDs, this approach does not support users who require granular, per-project customisation for settings such as poll_rate, services to monitor, or custom_metric_type_domains.

Investigation

To determine if this issue applies, an administrator should review their Terraform configuration and execution logs:

1. Check the signalfx_gcp_integration resource for the presence of the project_wif_configs block.
2. Confirm if the Terraform output contains the following warning:

Warning: Argument is deprecated
on signalfx.tf line [LINE_NUMBER], in resource "signalfx_gcp_integration" "[RESOURCE_NAME]":
Please use workload_identity_federation_config with projects instead project specific project_wif_configs.

3. Verify if the current implementation relies on a for_each loop to apply different monitoring logic (e.g., different service lists) to different GCP projects.

Resolution

To resolve the deprecation warning while preserving the ability to customise settings for each project, the resource block must be refactored to use the new top-level WIF attribute and the projects block.

Update the Authentication Attribute

Replace the project_wif_configs block with the workload_identity_federation_config attribute. This attribute accepts the JSON-encoded credentials configuration directly.

Refactor the Project Selection

Instead of defining the project ID within the WIF config block, use the projects block with the selected_project_ids argument. When used within a for_each loop, this ensures that each integration resource remains dedicated to a single project, allowing for unique parameters.

Implementation Example

The following code block demonstrates the corrected structure:

resource "signalfx_gcp_integration" "gcp_signalfx_integration_wif" {
  for_each = { for k, v in local.gcp_project_data : v.gcp_project_id => v }  name        = each.key
  enabled     = true
  poll_rate   = each.value.poll_rate
  services    = each.value.services_to_monitor
  auth_method = "WORKLOAD_IDENTITY_FEDERATION"  # Use the new supported attribute
  workload_identity_federation_config = jsonencode(local.credentials_config)  # Use the projects block to target the specific project in the loop
  projects {
    selected_project_ids = [each.value.gcp_project_id]
  }  # Additional granular settings remain supported
  use_metric_source_project_for_quota = true
  custom_metric_type_domains          = length(each.value.custom_domains) > 0 ? "${each.value.custom_domains}" : null
}

Key Considerations

• Consistency: Using workload_identity_federation_config at the top level aligns the configuration with the latest provider standards.
• Scalability: This "one-to-one" integration pattern (one resource per project via for_each) is the recommended approach when projects require different polling intervals or service filters, even when sharing the same WIF identity provider.
• Validation: Ensure that jsonencode is used if the credentials_config is defined as a map in Terraform locals.