I have created an API client library and Terraform provider for Okta's Management API. I am using Okta's Trusted Origin Management API within the Terraform provider to automate the provisioning of Trusted Origins in Okta.
I need help understanding how to import pre-existing Trusted Origins into the Terraform state file for a list of pre-existing Trusted Origins.
Say that Okta Trusted Origins are represented by the okta_trusted_origin Terraform resource and I have a list of URLs called host_urls.
variable "host_urls" {
description = "All the URLs for the Trusted Origin hosts"
type = "list"
default = [
"http://foo.com",
"http://bar.com",
"http://example.com"
]
}
resource "okta_trusted_origin" "host-urls" {
count = "${length(var.host_urls)}"
name = "${element(var.host_urls, count.index)}"
origin = "${element(var.host_Urls, count.index)}"
scopes = ["CORS", "REDIRECT"]
}
The “meta-parameter” count above defines how many copies of the resource to create. Each resource is created based on the Trusted Origins defined in the host_urls variable. In this case three Terraform resources will be created: host-urls[0], host-urls[1], and host-urls[2].
The problem I have is with the resource name under these conditions. Terraform imports resources based on the resource name, and this makes it difficult if the resource is identified by an ID in the data source where it pre-exists. Each Trusted Origin is uniquely identified in Okta by it's name, origin or ID, but Okta's API only allows GET operations based on ID. In other words, there is no way to get a Trusted Origin by the name or origin fields.
Here's what I'd like to do:
terraform import okta_trusted_origin.<origin-url>
where <origin-url> is a URL of a pre-existing Trusted Origin in Okta.
What is the best way to achieve what I am trying to do? Terraform's documentation is not leading me down any promising paths. Your help would be much appreciated!
Hi @jon-whit!
Terraform's current import facility is designed around importing one resource instance at a time, using an arbitrary string (to be interpreted by the provider as needed) as the identifier for the remote object to import.
In the example you gave, that means that each of those instances must be imported separately:
terraform import okta_trusted_origin.host-urls[0] tos10hu7rkbtrFt1M0g4
terraform import okta_trusted_origin.host-urls[1] 10hutos7rkM0g4Ft1btr
terraform import okta_trusted_origin.host-urls[2] utos10h7FtM01btrg4rk
The interpretation of that id argument is up to your provider, and so (aside from the requirement that it must be a string) you're limited only by the underlying API in what sort of identifiers you might accept here.
If the underlying API indeed only allows looking up these objects by the opaque id, then that is what users will need to provide on the command line. From skimming the API I see that there's also a means to list with a filter, which you could potentially use in one of the following ways:
(origin = ID), again failing if there isn't exactly one result.The usual convention is to use whatever unique identifier is most prominent in the UI of the target system. I'm not familiar enough with Okta to know what's best here, but I would suggest to pick something that is naturally unique and easy to copy-paste out of the Okta UI. Assuming this is the UI in question, it seems like the origin is the most likely candidate, but I'm not familiar enough to be sure:

I hope that helps! If I misunderstood the question, please let me know.
Perfect, thanks!
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Hi @jon-whit!
Terraform's current import facility is designed around importing one resource instance at a time, using an arbitrary string (to be interpreted by the provider as needed) as the identifier for the remote object to import.
In the example you gave, that means that each of those instances must be imported separately:
The interpretation of that id argument is up to your provider, and so (aside from the requirement that it must be a string) you're limited only by the underlying API in what sort of identifiers you might accept here.
If the underlying API indeed only allows looking up these objects by the opaque id, then that is what users will need to provide on the command line. From skimming the API I see that there's also a means to list with a filter, which you could potentially use in one of the following ways:
(origin = ID), again failing if there isn't exactly one result.The usual convention is to use whatever unique identifier is most prominent in the UI of the target system. I'm not familiar enough with Okta to know what's best here, but I would suggest to pick something that is naturally unique and easy to copy-paste out of the Okta UI. Assuming this is the UI in question, it seems like the origin is the most likely candidate, but I'm not familiar enough to be sure:
I hope that helps! If I misunderstood the question, please let me know.