Retain user group app assignments

[Omicron7]

We have a very distributed terraform setup where we use Okta with AWS SSO for user and permissions management. The same User and Group assignments can be made in different modules for different AWS Permission Sets by different developers. Okta user and group assignments are idempotent, meaning you can assign the same user multiple times in multiple places which only results in a single assignment in the Okta app. The flip side is that a single destroy of okta_app_user or okta_app_group_assignment completely removes the user/group from the app, even though it may still exist in multiple other terraform modules.

This adds retain_assignment arguments to both the okta_app_user and okta_app_group_assignment resources. This optional attribute allows terraform to remove the resource from state when it is destroyed, but to retain the user/group assignments on the associated Okta app. Documentation changes have been added warning that using this feature will result in the need to possibly manually remove user/group assignments in the future.

Tests have been updated and run and are passing against our instance of oktapreview.

Let me know what you think and if you'd like any changes.

[bogdanprodan-okta]

Hi, @Omicron7! Thanks for submitting this PR! I'll review it ASAP.

[noinarisak]

Hi, @Omicron7! Thanks for submitting this PR.

I was chatting with @bogdanprodan-okta and I have a concern about this PR because it disrupts the TF lifecycle, ie modifying the tfstate when you have retain_assignment true and possibly manually removing user/groups on our Okta tenant. I'm not connecting the dots on the pain of what this PR will resolve for the larger community. In the end, we are trying to make sure all the PRs add value across the community by balancing out more explicit implementation than implicit ones. I hope that helps with the hesitation on this PR.

Could you detail out the scenario for us, maybe sample implementation via gist, so we can evaluate it again. Thanks again and sorry for asking for more details!

[Omicron7]

@noinarisak @bogdanprodan-okta Thanks for the responses. I understand that this somewhat disrupts the normal terraform lifecycle and hoped to warn users of that fact through the documentation updates. I'll try to create an example here that shows the issue we are running into and why this PR solves it.

We have a single Okta app using AWS SSO, we'll call it aws-sso.
We have a Terraform module (aws-okta-permissions) for adding permission sets to AWS that grant Okta users/groups access to AWS permissions. A simplified interface would be something like this (the actual module is in a private repo):

module "permissions" {
  source         = "aws-okta-permissions"
  name           = "Network Administrators"
  okta_users     = ["user.name", "user2.name2"]
  okta_groups    = ["group name"]
  iam_policy_doc = iam_policy.json
}

Internally, this module uses data sources to lookup the users/groups in Okta, assign them to the aws-sso app, and grant them the permissions in AWS. We use this module in multiple places in our larger AWS infrastructure repo, as well in other smaller application repos.

The problem we are running into is that assigning users/groups to an app in Okta is idempotent, meaning that we can assign the same user/group in multiple modules (locations in the AWS repo, and smaller repos), but it results in only one copy of the user/group assigned in the okta app. Deleting user/group from an app is not idempotent.

Here's an example using REST

POST /api/v1/apps/{appId}/users { "Id": "abc123", ...}
POST /api/v1/apps/{appId}/users { "Id": "abc123", ...}
DELETE /api/v1/apps/{appId}/users/abc123

Both POST return 2xx responses and result in the user abc123 being assigned to the app. The single DELETE removes the user. In our terraform scenario, the POSTs happen in 2 different modules, each module now "owns/manages" the user assignment to the app. If we destroy one of the modules (DELETE request), Okta removes the user assignment and de-provisions them from the app. But we still have a module that "owns" that user assignment to the app, but it is now out of sync/drift, and the user in question has lost all permissions because Okta deprovisioned them.

Here's a contrived terraform example.

In Okta, we have the following users/groups

users:
  - Tony.Stark
  - Bruce.Banner
  - Natasha.Romanoff
  - Nick.Fury
groups:
  avengers:
    - Tony.Stark
    - Bruce.Banner
    - Natasha.Romanoff

In Terraform, the following permissions are defined for AWS/Okta. They are defined in different git repos, but all use the same Okta AWS SSO app and AWS account.

# github.com/Avengers/avengers/permissions.tf
module "avengers" {
  source = "aws-okta-permissions"
  name = "The Avengers"
  okta_groups = ["avengers"]
}

# github.com/StarkIndustries/ultron/permissions.tf
module "ultron" {
  source = "aws-okta-permissions"
  name = "Ultron"
  okta_users = ["Tony.Stark", "Bruce.Banner"]
}

# github.com/StarkIndustries/insight/permissions.tf
module "project_insight" {
  source = "aws-okta-permissions"
  name = "Project Insight"
  okta_users = ["Nick.Fury", "Tony.Stark", "Natasha.Romanoff"]
}

Each instance of the aws-okta-permissions internally looks up the users/groups (data source) from Okta and assigns them (okta_app_user, okta_app_group_assignment respectively) to the aws-sso app. If for any reason, we want to destroy one of these modules, say ultron, it will result in destroying the associated okta_app_user for both Tony.Stark and Bruce.Banner. This will cause Okta to deprovision those users from the AWS SSO app. Those user will no longer be able to login to AWS even though they have permissions and okta_app_user resources defined in other places.

By using the retain_assignment attribute, we can tell terraform NOT to DELETE the okta_app_user or okta_app_group_assignment from Okta when they are destroyed in terraform. With those attributes enabled, Tony.Stark and Bruce.Banner would still be able to login to AWS and access their other assigned permissions. They could not access ultron any more as those associated AWS permissions were destroyed.

In contrast, If we destroyed project_insight with retain_assignment enabled, Nick.Fury, Tony.Stark, and Natasha.Romanoff's AWS permissions would be removed for that project, but all 3 would still be able to log in. Tony.Stark and Natasha.Romanoff would still have permissions from the avengers module, but Nick.Fury, even though he could still log in, would have no permissions in AWS.

Conclusion

I hope this helps to clarify the issues we are encountering any why this PR solves it. I thought it could be useful for others, and so made a PR rather than just using a forked provider for ourselves. I'm open to any changes in wording or documentation to let others know this is an advanced feature that disrupts the standard terraform lifecycle and that they should be aware of that before enabling it. I'm positive I've seen this pattern in some other providers that also had idempotent resources, but haven't been able to find them again.

Let me know if you have any more questions.

[Omicron7]

Here's another Terraform resource that does something similar:
google_project_service

You can set the disable_on_destroy attribute to false to cause terraform to remove the resource from state, but not issue the DELETE to the google project.

[bogdanprodan-okta]

Hi, @Omicron7! I think we can merge your PR since it doesn't have any breaking changes to the existing infrastructure.