Functionality Change - okta_admin_role_custom_assignments should use binding Id?

[exitcode0]

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

Description

Currently it appears that okta_admin_role_custom_assignments uses <resource_set_id>/<custom_role_id> as the ID in the state file the result is that if two okta_admin_role_custom_assignments attempt to reference the same resource set and custom role ID they will conflict with one another Should we instead use the binding ID for this resource? this would allow two okta_admin_role_custom_assignments to re-use the same resource set and custom role but specify different members

This is useful if you want to define your Okta admin permissions in seperate files - we do this to attempt to keep all related resources within the same TF file, this makes for easier deprecation when the time comes as you don't need to go searching for references elsewhere (e.g Business Unit "XYZ" no longer needs admin permissions to okta, just delete okta_admin_xyz.tf)

New or Affected Resource(s)

• okta_admin_role_custom_assignments

Potential Terraform Configuration

resource_sets.tf

resource "okta_resource_set" "all_groups" {
  label       = "All Groups"
  description = "All groups in the okta instance"
  resources = [
    "https://${var.okta_org_name}.${var.okta_base_url}/api/v1/groups",
  ]
}
resource "okta_admin_role_custom" "view_groups" {
  # use this if you want to avoid giving out okta.users.read
  # okta.users.read can allow an admin to view sensitive data in the user schema
  label       = "View-Only access to Groups"
  description = "Allows an admin to view groups"

  permissions = [
    "okta.groups.read"
  ]
}

okta_admin_example1.tf

resource "okta_group" "example1" {
    name = "okta_example1"
    description = "houses the example1 team"
}
resource "okta_admin_role_custom_assignments" "example1" {
    custom_role_id = okta_resource_set.all_groups.id
    resource_set_id = okta_admin_role_custom.view_groups.id
    members = [ 
        okta_group.example1.id
     ]
}

okta_admin_example2.tf

resource "okta_group" "example2" {
    name = "okta_example2"
    description = "houses the example2 team"
}
resource "okta_admin_role_custom_assignments" "example2" {
    custom_role_id = okta_resource_set.all_groups.id
    resource_set_id = okta_admin_role_custom.view_groups.id
    members = [ 
        okta_group.example2.id
     ]
}

References

• Similar related request #1153

[monde]

Thanks @exitcode0, I'll look into this. Your research notes seems logical to me so far. Okta internal reference: https://oktainc.atlassian.net/browse/OKTA-585640

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days

[JasonBuckner]

Seems related to #1491