Checklist
Describe the problem you'd like to have solved
We have a fairly static set of Auth0 connections from which we draw bodies of users. Adding new bodies of users is fairly rare. Ergo, we have a single Terraform root module that controls each Auth0 connection.
We dynamically generate Auth0 applications/clients. Adding new templated Auth0 application/clients is fairly regular. Ergo, we have a single Terraform root module that can be run in multiple tf workspaces with different variables to generate a (theoretically) infinitely scalable number of application/clients.
Each application/client should be associated with a dynamic combination of connections, dependent on the variables passed to the application/client. For example, I might spin up an application/client that should only be reachable by two of my customers, and I might spin up a near-identical application/client that should only be reachable by one of my customers and our internal team.
Currently, there is no way for our lovely application/client terraform module to automatically associate the brand spanking new application with an existing connection. One has to spin up the application and either manually set the 'toggle' slider from the application/client's 'connections' tab in the dashboard, OR one has to edit the connections terraform root module and add the client_id to the enabled_clients argument for the connection.
Why is this bad?
- Manual action sucks, so that rules out the dashboard like right away.
- Having to tweak two terraform modules in a specific order is a pretty irritating barrier to automation. It means two git pushes.
- Deleting an application/client before it was removed from the 'connections' terraform module means the 'connections' terraform module would immediately become invalid (because you better believe I'm not hardcoding client_ids, I'm using an auth0_client datasource) and would need edited and the offending client removed (which is also hard because THE APPLICATION IS ALREADY GONE and the data source that refers to it is now invalid. We're talking some direct terraform state work if the application destruction wasn't done in a perfectly precise order).
- Codified methods of determining what application/clients are reachable by what users is particularly difficult. I have to go through each
connection terraform remote module and figure out what each set of users has access to, then filter that by the application I care about... instead of simply asking the application.
- All companies on the planet have 'legacy' junk that was set up manually by some yahoo, right? We're no different. We have some 'connections' which are not terraformed. I can't edit these connections via terraform for bureaucracy reasons, which means I have no codifiable recourse to attaching new application/clients to them!
In short, managing the association between application/clients and connections must be done in multiple places in a specific order... and it shouldn't be that way! This really hamstrings the usefulness of Terraform in general, where a single terraform apply can bring up all the resources necessary for a specific modular subset of your overall infrastructure.
Describe the ideal solution
Taking a page from the AWS provider's book, let's look at how they handle aws_security_groups, which are a resource that be thought of akin to a grouping of firewall rules. "If the connection comes from the 10.0.0.0/8 CIDR, allow it, but if it comes from 10.1.0.0/16, deny it." This is a resource - like your auth0_connection - that is often associated with several other resources (rules) - like your auth0_clients.
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group
At first glance, the security group is set very similar to allowed clients in your connections resource - a list of 'ingress' and 'egress' rules. However, the AWS provider also provides the following resource:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group_rule
This resource allows you to specify an arbitrary rule and assign it to an existing security group. If you had a central security group (that controlled access to, say, a virtual machine) and created a fresh resource that should have access to the security group, you could simply create an aws_security_group_rule resource and associate it to the security group INSTEAD of having to hunt down the existing aws_security_group's terraform module and plug in a data source (that can't be guaranteed to continually exist).
Using this method, one generates an empty security group in a single terraform module (call it module A) (much like generating an unassociated auth0_connection) that protects an asset with a 'deny' flag, and then any time someone creates a terraform module (call it module B) with resources that should be allowed to pass the security group, module B simply adds the aws_security_group_rule resource to the security group built in module A. Module B can be templated and run in many different terraform workflows to always create a rule and always plug it into the security group from A, without ever needing to edit and re-run A... and removing a rule is as simple as destroying module B.
I would love to see an auth0_connection_client_association resource that follows this same strategy.
Alternatives and current workarounds
Manually doing things in the dashboard, in the cases where I cannot edit a connection via terraform (ie, data source only)
Additional context
Kudos to you for working on the provider in general!
