Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AccessPolicy] Incorrect management of "require" with multiple Okta IdPs #3425

Closed
3 tasks done
notdodo opened this issue Jul 2, 2024 · 3 comments · Fixed by #3579
Closed
3 tasks done

[AccessPolicy] Incorrect management of "require" with multiple Okta IdPs #3425

notdodo opened this issue Jul 2, 2024 · 3 comments · Fixed by #3579
Labels
kind/bug Categorizes issue or PR as related to a bug. service/access Categorizes issue or PR as related to the Access service. triage/accepted Indicates an issue or PR is ready to be actively worked on. triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log. workflow/synced
Milestone

Comments

@notdodo
Copy link

notdodo commented Jul 2, 2024

Confirmation

  • This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
  • I have searched the issue tracker and my issue isn't already found.
  • I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.9.0
on darwin_arm64

  • provider registry.terraform.io/cloudflare/cloudflare v4.36.0

Affected resource(s)

cloudflare_access_policy

Terraform configuration files

resource "cloudflare_access_application" "poc1" {
  account_id = var.account_id
  name = "TEST-NOTDODO"
  domain = "mytest.example.com"
  type = "self_hosted"
  session_duration          = "24h"
  auto_redirect_to_identity = false
}

variable idp_prod {
  default = "<idp_prod_id>"
}

variable idp_stag {
  default = "<idp_prod_id>"
}

resource "cloudflare_access_policy" "poc1policy1" {
  name           = "staging policy"
  account_id     = var.account_id
  application_id = cloudflare_access_application.poc1.id
  precedence     = "1"
  decision       = "allow"
  include {
    login_method = [var.idp_prod, var.idp_stag]
  }
  require {
    okta {
      identity_provider_id =  var.idp_prod
      name = ["mygrouponprod"]
    }
    okta {
      identity_provider_id =  var.idp_stag
      name = ["mygrouponstag"]
    }
  }
}

Link to debug output

https://gist.github.com/notdodo/c3524ed143e5574632a4ce63a337e158

Panic output

No response

Expected output

No changes during the plan.

Actual output

Terraform plan shows chagens to apply even though there aren't, apparently.

  # cloudflare_access_policy.poc1policy1 will be updated in-place
  ~ resource "cloudflare_access_policy" "poc1policy1" {
        id                             = "7f0042d7-983b-407d-aa13-a4f20a9e418f"
        name                           = "staging policy"
        # (8 unchanged attributes hidden)

      ~ require {
            # (16 unchanged attributes hidden)

          ~ okta {
              ~ identity_provider_id = "<idp_prod_id>" -> "<idp_stag_id>"
              ~ name                 = [
                    "mygrouponprod",
                  - "mygrouponstag",
                ]
            }
          + okta {
              + identity_provider_id = "<idp_stag_id>"
              + name                 = [
                  + "mygrouponstag",
                ]
            }
        }

        # (1 unchanged block hidden)
    }

It seems that multiple requires are not correctly parsed during the refresh so wrong changes are always shown

Steps to reproduce

I manually created a policy that accept 2 possible Okta IdPs with different groups on Cloudflare Access for an application.

Screenshot 2024-07-02 at 09 15 47

I imported the application resource with

terraform import cloudflare_access_application.poc1 <account_id>/<application_id>

Creating the same policy on terraform with 2 Okta IdPs and require the plan shows that the refresh/get of the remote resource has a bug:

The okta.identity_provider_id is set to the last value present during the apply and the okta.name contains a list of both groups.

          ~ okta {
              ~ identity_provider_id = "<idp_prod_id>" -> "<idp_stag_id>"
              ~ name                 = [
                    "mygrouponprod",
                  - "mygrouponstag",
                ]
            }
          + okta {
              + identity_provider_id = "<idp_stag_id>"
              + name                 = [
                  + "mygrouponstag",
                ]
            }

The same is also valid when using new reusable access policies

Additional factoids

I think that the bug is generated here: the OktaID is a single value and not append like the groups. Here is the generated output that is not expected.

References

No response

@notdodo notdodo added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jul 2, 2024
Copy link
Contributor

github-actions bot commented Jul 2, 2024

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

@github-actions github-actions bot added the triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log. label Jul 2, 2024
@jacobbednarz jacobbednarz added triage/accepted Indicates an issue or PR is ready to be actively worked on. service/access Categorizes issue or PR as related to the Access service. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jul 3, 2024
@notdodo
Copy link
Author

notdodo commented Jul 16, 2024

@jacobbednarz sorry to bump this but is this bug valid? are you tackling this internally?

Copy link
Contributor

This functionality has been released in v4.40.0 of the Terraform Cloudflare Provider.

Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. service/access Categorizes issue or PR as related to the Access service. triage/accepted Indicates an issue or PR is ready to be actively worked on. triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log. workflow/synced
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants