As an administrator, I should be able to restrict Resources being created in Twingate which have a duplicate name, IP, or CIDR – presumably associated with the same Connector (as it is likely that you may have the same private CIDR across two different DCs).
Via the API, the call should be rejected with an HTTP 4xx error indicating the client should choose a different name, IP, or CIDR, and that the one they’ve chosen is already in-use for that connector.
At the present moment, if folks don’t go through the Terraform automation, a manual resource will be added, and, then, the automation runs and adds the same resource. I’d like to be able to have some manual resources added, but, ensure the ones added through automation do not get duplicated.
Thanks for your feedback! Uniqueness is an interesting problem for Resources. Let me share our perspective on why we don’t enforce uniqueness here.
The main use case for non-unique Resource addresses (even within the same Remote Network) is multiple definitions for the same physical resource with different protocol restrictions for different users. For example, say I have an “Internal Server” Resource. I want to give most users access to that Resource with ports 80 and 443 open but I also want to give the IT team access to port 22. You would do that by defining two Twingate Resources with the same exact address but different protocol restrictions (TCP 80, 443 for one and TCP 22, 80 and 443 for the other) then I would assign them to different Twingate Groups.
Secondly, and this might be stretching the definition of “uniqueness”, it’s possible and sometimes recommended to have overlapping wildcard Resources. Twingate uses the Resource with the most specific definition, so if both 10.0.0.10 and 10.0.0.0/24 are Resources, when you access 10.0.0.10, Twingate will use the more specific Resource.
I can see the benefit in Terraform, thought our current suggestion would be to stick with Terraform or manual management instead of mixing the two for the same Resource. Feel free to open an issue on the Terraform provider about that and we’ll investigate whether we can do that, but we might give the same recommendation there to not mix the two.