IAM Auth option's default value leading to misleading terraform plan

[giannifiore]

Description

Terraform plan for RDS Proxy consistently detects changes that are false positives,
as it is trying to set value null instead of "DISABLED" for auth.iam_auth.
I am not even using IAM auth for this proxy.

Versions

• Module version [Required]: 3.1.0
• Terraform version: 1.6.2
• Provider version(s): hashicorp/aws v5.25.0

Reproduction Code [Required]

Steps to reproduce the behavior:

I am not using workspaces,
I have cleared the local cache and performed again terraform init and terraform plan,

Sharing steps:

Considering the complexity of the command to create a RDS proxy (many inputs that depends on your own environment and subnets and secrets), I am sharing here an example in my own environment that may not be reproducible as is (need to set your values) in yours

module "aws_rds_proxy" {
  source  = "terraform-aws-modules/rds-proxy/aws"
  version = "3.1.0"

  name            = local.proxy_identifier
  iam_role_name   = "${local.proxy_identifier}-role"

  vpc_subnet_ids         = var.subnet_ids
  vpc_security_group_ids = var.security_group_ids
  require_tls            = var.require_tls

  endpoints = {
    read_write = {
      name                    = "read-write-endpoint"
      vpc_subnet_ids          = var.subnet_ids
      vpc_security_group_ids  = var.security_group_ids

    },
    read_only = {
      name                    = "read-only-endpoint"
      vpc_subnet_ids          = var.subnet_ids
      vpc_security_group_ids  = var.security_group_ids
      target_role             = "READ_ONLY"
    }
  }

  auth = {
    "superuser" = {
      description             = "Target database superuser password"
      secret_arn              = var.target_superuser_secret_arn
    }
  }

  # target RDS cluster or instance
  engine_family               = var.target_engine_family
  target_db_cluster           = var.target_type == "cluster"
  db_cluster_identifier       = var.target_identifier
}

Expected behavior

Given a basic configuration of a RDS Proxy as the one reported, Given a terraform apply was completed successfully before,
When a terraform plan command is executed,
Then the command should result in an empty plan

Actual behavior

Given a basic configuration of a RDS Proxy as the one reported, Given a terraform apply was completed successfully before,
When a terraform plan command is executed,
the command consistently results in a non-empty plan as follows:

  # module.aurora_cluster_postgres.module.aurora_postgres_aws_rds_proxy[0].module.aws_rds_proxy.aws_db_proxy.this[0] will be updated in-place
  ~ resource "aws_db_proxy" "this" {
        id                     = "pan-dev-aurora-postgres-cluster-proxy"
        name                   = "pan-dev-aurora-postgres-cluster-proxy"
        tags                   = {}
        # (10 unchanged attributes hidden)

      ~ auth {
          - iam_auth                  = "DISABLED" -> null
            # (4 unchanged attributes hidden)
        }
    }

Terminal Output Screenshot(s)

Additional context

[giannifiore]

as a workaround, setting iam_role to "DISABLED" explicitly solves the issue

auth = {
    "superuser" = {
      description             = "Target database superuser password"
      secret_arn              = var.target_superuser_secret_arn
      iam_auth                 = "DISABLED"
    }
  }

so my suggestion would be to change the default value for iam_auth (in main.tf file of the module) from null to "DISABLED"

[bryantbiggs]

we default to null for optional values unless there is a strong reason to set a value - this would be something the provider would need to clean up

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue was automatically closed because of stale in 10 days

[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.