We are in the process of removing all of the service accounts and their associated API keys that we've given to developer teams to create the resources via Terraform in our CIAM tenants.

We are moving towards creating an API application with OAuth2.0/public key that the dev teams will utilize to configure their Okta provider for terraform.

I created the API application and its public key and granted scopes to that API application that their TF runner should need, but I found that I have to grant an elevated admin role to the application as well for for it to work. Simply having the scopes granted doesn't actually give them the permissions to do things via TF provider and that clientid/public key.

As a rough test I've found that granting the API application a high level admin role works, but that creates a potential problem.

The problem is we have many terraform repos for application integrations...one for each of our different application teams...and one teams TF repo should not be able to manage other groups/apps/etc. I'm worried that if that application has that high level admin role assigned and I give them okta.groups.manage, okta.applications.manage, etc..which they absolutely need for their TF work that they will be able to accidentally modify/delete/change ANY group/application/idp or other object type that I grant them the .manage scope for.

I haven't testing this, but it would be ideal if the .manage scopes gave them the permission to modify resources actually created by them, but I'm pretty sure that is not the case.

So how can I manage this? How can I give different engineering teams the .manage scopes they need for the TF runner application but ensure they can't modify OTHER teams resources that they shouldn't control.

Is some sort of application of resource sets the ONLY way to accomplish this?