Behavior change in okta_group_memberships resource >=3.26

[dli-spoton]

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 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
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v1.0.4
on linux_amd64

Affected Resource(s)

• okta_group_memberships

Terraform Configuration Files

resource "okta_group_memberships" "group_a_direct" {
  group_id = okta_group.group_a.id
  users = ["00ue640grabcdbA04465", "00u4pjzdcbalzJCP123"] # two users
}

resource "okta_group_rule" "group_b_to_a_rule" {
  name                  = "Group B -> A rule" # say this contains 10 additional users
  status                = "ACTIVE"
  group_assignments     = [okta_group.group_a.id]
  expression_type       = "urn:okta:expression:1.0"
  expression_value      = "isMemberOfAnyGroup(\"${okta_group.group_b.id}\")"
  remove_assigned_users = true
}

Debug Output

Panic Output

Expected Behavior

In <=3.25, the resource only tracked the state of the users defined in the config. Would ignore all drift in the target group.
In the example, it would ignore any users synced from group b by the group rule.

Actual Behavior

In >=3.26, the resource tracks all group members and will mark any users added outside of the Terraform resource as drift.
In the example, it'll mark all users synced from group b by the group rule as drift and try to remove them.

Steps to Reproduce

1. terraform apply

Important Factoids

This is a recreation of #1094 as requested there.
I can work around this if needed by restructuring groups. (unpleasant but doable)
Mainly looking for confirmation this is an intended behavior change and won't be fixed.

References

• okta_group_memberships undoes okta_group_rule users in >=3.26.0 #1094

[virgofx]

Personally I think that having okta_group_memberships be authoritative is the correct behavior. Meaning it should be able to do a global set for all group memberships/ overwriting any drift.

However, I understand the other side of the coin. Either way, adding documentation to the provider resource docs would help clarity-wise.

[monde]

Linking related issues #1119, #1094
Thanks @dli-spoton, your explanation of the previous behavior is concise.

I see the strong case for reverting to the previous behavior of okta_group_memberships resource. In addition add in the ability for it to concern itself for all users in the group even if they've been added outside of the resource. Looking back at the recent changes I was involved with you can see my comments about how the established implementation was muddy:
https://github.com/okta/terraform-provider-okta/blob/master/okta/resource_okta_group_memberships.go#L148-L155

Reverting back to the established behavior and accounting for the new behavior using a flag is the solution I'm thinking about. Check out this example on my thoughts.

data "okta_group" "example" {
  name = "Some Group"
}

resource "okta_group_memberships" "specific_users" {
  group_id = data.okta_group.example.id
  users = ["a", "b"]

  # classic/default behavior only cares if users a or b are removed or
  # if the hard coded users slice is changed in the config file
}

resource "okta_group_memberships" "all_users" {
  group_id = data.okta_group.example.id
  users = data.okta_group.example.users

  track_all_users = true
  # will show drift if users are added/removed from the group
  # outside of this resource after the last apply
}

Looking for feedback from @parente @tmatilai @exitcode0 @dli-spoton @virgofx

[virgofx]

I'm in favor of the flag. It satisfies both use cases. As for what the default action is -- no preference there - maybe revert to how it was before such that it's opt-in.

[dli-spoton]

I'm also in favor of the flag.

Personally, I think the default should be the new behavior, since it's more inline with how generally Terraform resources are expected to behave. But it is more disruptive and probably not worth it.

One nice to have that's beyond the scope of this issue is to have the option to only ignore users added by group rules, but be authoritative for all manually managed users. The UI reports if the user is manual or group rule managed, but I don't think the APIs return this information, so it probably a much bigger ask.

[monde]

One nice to have that's beyond the scope of this issue is to have the option to only ignore users added by group rules, but be authoritative for all manually managed users. The UI reports if the user is manual or group rule managed, but I don't think the APIs return this information, so it probably a much bigger ask.

That one sounds cool. I just checked in postman that the response to GET /api/v1/groups/{groupId}/users doesn't list hte origin of membership like it does in the UI. In my test org I added a user to the group by UI and added another in the group by rule. Sad.

[tmatilai]

A flag would be perfect for me, too.

Personally, I think the default should be the new behavior, since it's more inline with how generally Terraform resources are expected to behave.

I agree on this. The downside is that it's still a breaking change to the earlier behaviour, but that has been like this already for a couple of releases. But for me personally that wouldn't matter much.

@monde sorry for not responding to your request earlier. Been busy weeks, and now I'll be probably even offline for a couple of weeks. 🙂

[dli-spoton]

@lucascantor that's a pagination bug introduced in 3.26. Issue #1119. Should've been fixed in 3.28.

[lucascantor]

@dli-spoton thanks so much for the heads up. Unfortunately, we can't upgrade to 3.28 yet due to it reintroducing #1079

[monde]

Working on this PR " Reestablish old behavior of okta_group_memberships resource" #1161 . Trying to get a v3.29.0 release out today.

[monde]

Hey all, let me know if https://github.com/okta/terraform-provider-okta/releases/tag/v3.29.0 fixes this for you. okta_group_memberships reverted back to it's original behavior. If you want it to track all users set the property track_all_users=true. Also took extra care to not deviate from the ordering of users ids as they were originally assigned in the update.
https://registry.terraform.io/providers/okta/okta/latest/docs/resources/group_memberships

[dli-spoton]

3.29 looks good to me.

[monde]

Going to close this one 🤞