cloudflare_access_policy: changes always detected for saml -> identity_provider_id

[merykozlowska]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.1.7
on darwin_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.12.0

Affected resource(s)

cloudflare_access_policy

Terraform configuration files

resource "cloudflare_access_policy" "ops_insights_policy" {
  application_id = "<redacted>"
  zone_id        = "<redacted>"
  name           = "Allow Access to Ops-Insights Group"
  precedence     = "1"
  decision       = "allow"

  include {
    saml {
      attribute_name       = "groups"
      attribute_value      = "Ops-Insights"
      identity_provider_id = "<redacted>"
    }
  }
}

Debug output

See attached file: tf.log

Panic output

No response

Expected output

No changes to cloudflare_access_policy resource.

Actual output

Terraform always detects changes:

Terraform will perform the following actions:

  # cloudflare_access_policy.ops_insights_policy will be updated in-place
  ~ resource "cloudflare_access_policy" "ops_insights_policy" {
        id             = "<redacted>"
        name           = "Allow Access to Ops-Insights Group"
        # (4 unchanged attributes hidden)

      ~ include {
            # (11 unchanged attributes hidden)

          ~ saml {
              + identity_provider_id = "<redacted>"
                # (2 unchanged attributes hidden)
            }
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to reproduce

1. Create an Access policy using SAML as the include condition like in the example configuration.
2. Run terraform plan.

Additional factoids

It looks like this may be related to the fact that Cloudflare API doesn't return identity_provider_id (anymore?). If that is indeed the case would it be possible to raise it with the team responsible for the endpoint internally? I'm happy to create also a support request if that helps.

References

No response

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[merykozlowska]

The log is attached as a file.

[jacobbednarz]

ignore the bot, it doesn't yet know how to read attachments :)

does this still work as you expect without the identity_provider_id in the schema?

[merykozlowska]

ignore the bot, it doesn't yet know how to read attachments :)

but it's saying that no one will care about my issue 😢

does this still work as you expect without the identity_provider_id in the schema?

sorry, not sure if i understand the question 😓 do you mean this schema? or if we remove this id from the configuration?

[jacobbednarz]

just your configuration; I'm wondering if this field is no longer required to associate the identity provider without it.

[merykozlowska]

sorry for the delay in getting back to you!
so i've just tried creating a new policy like in my initial example but without identity_provider_id and it seems to work correctly.
does this mean that the policy gets associated with the IdP automagically or that it actually isn't associated with a specific IdP at all? i'm wondering what would happen if we had more than one IdP (and unfortunately don't have an easy way of testing it right now) 🤔

[sarayourfriend]

I have this same issue with GitHub and even the email setting when it is empty.

Plan output (sanitized):

  # module.access.cloudflare_access_policy.allow["airflow"] will be updated in-place
  ~ resource "cloudflare_access_policy" "allow" {
        id             = "<redacted>"
        name           = "airflow allow policy"
        # (4 unchanged attributes hidden)

      ~ include {
            # (11 unchanged attributes hidden)

          + github {
              + identity_provider_id = "<redacted>"
              + name                 = "WordPress"
              + teams                = [
                  + "openverse-maintainers",
                ]
            }
        }
      - include {
          - any_valid_service_token = false -> null
          - certificate             = false -> null
          - device_posture          = [] -> null
          - email                   = [] -> null
          - email_domain            = [] -> null
          - everyone                = false -> null
          - geo                     = [] -> null
          - group                   = [] -> null
          - ip                      = [] -> null
          - login_method            = [] -> null
          - service_token           = [] -> null

          - github {
              - identity_provider_id = "<redacted>" -> null
              - name                 = "WordPress" -> null
              - teams                = [
                  - "openverse-maintainers",
                ] -> null
            }
        }
    }

  # module.access.cloudflare_access_policy.allow["django-admin"] will be updated in-place
  ~ resource "cloudflare_access_policy" "allow" {
        id             = "<redacted>"
        name           = "django-admin allow policy"
        # (4 unchanged attributes hidden)

      ~ include {
            # (11 unchanged attributes hidden)

          + github {
              + identity_provider_id = "<redacted>"
              + name                 = "WordPress"
              + teams                = [
                  + "openverse-maintainers",
                ]
            }
        }
      - include {
          - any_valid_service_token = false -> null
          - certificate             = false -> null
          - device_posture          = [] -> null
          - email                   = [] -> null
          - email_domain            = [] -> null
          - everyone                = false -> null
          - geo                     = [] -> null
          - group                   = [] -> null
          - ip                      = [] -> null
          - login_method            = [] -> null
          - service_token           = [] -> null

          - github {
              - identity_provider_id = "<redacted>" -> null
              - name                 = "WordPress" -> null
              - teams                = [
                  - "openverse-maintainers",
                ] -> null
            }
        }
    }

  # module.access.cloudflare_access_policy.deny["airflow"] will be updated in-place
  ~ resource "cloudflare_access_policy" "deny" {
        id             = "<redacted>"
        name           = "airflow deny policy"
        # (4 unchanged attributes hidden)

      + include {
          + email = []
        }
    }

  # module.access.cloudflare_access_policy.deny["django-admin"] will be updated in-place
  ~ resource "cloudflare_access_policy" "deny" {
        id             = "<redacted>"
        name           = "django-admin deny policy"
        # (4 unchanged attributes hidden)

      + include {
          + email = []
        }
    }

Plan: 0 to add, 4 to change, 0 to destroy.

And here's the TF module itself:

locals {
    global_deny_emails = []
    global_allow_emails = []

    applications = {
        airflow = {
            domain = "airflow.openverse.engineering"
            allow_emails = []
            deny_emails = []
        }
        django-admin = {
            domain = "api.openverse.engineering/admin"
            allow_emails = []
            deny_emails = []
        }
    }
}

resource "cloudflare_access_application" "this" {
    for_each = local.applications
  account_id                = var.account_id
  name                      = each.key
  domain                    = each.value.domain
  type                      = "self_hosted"
  session_duration          = "24h"
  auto_redirect_to_identity = false
}

data "cloudflare_access_identity_provider" "github_login" {
    account_id = var.account_id
    name = "GitHub Openverse OAuth"
}

resource "cloudflare_access_policy" "deny" {
    for_each = toset(keys(local.applications))
  application_id = cloudflare_access_application.this[each.key].id
  account_id     = var.account_id
  name           = "${each.key} deny policy"
  precedence     = 1
  decision       = "deny"

  include {
    email = concat(
        local.global_deny_emails,
        local.applications[each.key].deny_emails,
    )
  }
}

resource "cloudflare_access_policy" "allow" {
    for_each = toset(keys(local.applications))
  application_id = cloudflare_access_application.this[each.key].id
  account_id     = var.account_id
  name           = "${each.key} allow policy"
  precedence     = 2
  decision       = "allow"

  include {
    email        = concat(
        local.global_allow_emails,
        local.applications[each.key].allow_emails
    )
    email_domain = toset(["<redacted>"])
    github {
        identity_provider_id = data.cloudflare_access_identity_provider.github_login.id
        name = "WordPress"
        teams = ["openverse-maintainers"]
    }
  }
}

It applies cleanly and doesn't appear to actually cause any changes to the configuration. The identity provider IDs all match and everything.

[github-actions]

Marking this issue as stale due to 90 days of inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 7 days it will automatically be closed. Maintainers can also remove the lifecycle/stale label.
If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[victor10x]

I'll just note the similar churn I was seeing before is now resolved with these versions:

$ terraform version
Terraform v1.3.6
on linux_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.31.0